$1 M L$

By François Pottier and Didier Rémy

1.1 Preliminaries

Names and renaming

Mathematicians and computer scientists use names to refer to arbitrary or unknown objects in the statement of a theorem, to refer to the parameters of a function, etc. Names are convenient because they are understandable by humans; nevertheless, they can be tricky. An in-depth treatment of the difficulties associated with names and renaming is beyond the scope of the present chapter: we encourage the reader to study Gabbay and Pitts' excellent series of papers (Gabbay and Pitts, 2002; Pitts, 2002b). Here, we merely recall a few notions that are used throughout this chapter. Consider, for instance, an inductive definition of the abstract syntax of a simple programming language, the pure

λ

-calculus:

t ::= z | λ z . t | t t

Here, the meta-variable

z

ranges over an infinite set of variables - that is, names-while the meta-variable t ranges over terms. As usual in mathematics, we write "the variable

z

" and "the term

t

" instead of "the variable denoted by

z

" and "the term denoted by t". The above definition states that a term may be a variable

z

, a pair of a variable and a term, written

λ

z.t, or a pair of terms, written

t_{1} t_{2}

. However, this is not quite what we need. Indeed, according to this definition, the terms

λ z_{1} \cdot z_{1}

and

λ z_{2} \cdot z_{2}

are distinct, while we would like them to be a single mathematical object, because we intend

λ z . z

to mean "the function that maps

z

z

"- a meaning that is independent of the name

z

. To achieve this effect, we complete the above definition by stating that the construction

λ

z.t binds

z

within

t

. One may also say that

λ z

is a binder whose scope is

t

. Then,

λ z . t

is no longer a pair: rather, it is an abstraction of the variable

z

within the term

t

. Abstractions have the property that the identity of the bound variable does not matter; that is,

λ z_{1} . z_{1}

and

λ z_{2} . z_{2}

are the same term. Informally, we say that terms are considered equal modulo

α

-conversion. Once the position and scope of binders are known, several standard notions follow, such as the set of free variables of a term

t

, written

f v (t)

, and the capture-avoiding substitution of a term

t_{1}

for a variable

z

within a term

t_{2}

, written

[z \mapsto t_{1}] t_{2}

. For conciseness, we write

f v (t_{1}, t_{2})

for

f v (t_{1}) \cup f v (t_{2})

. A term is said to be closed when it has no free variables.

A renaming is a total bijective mapping from variables to variables that affects only a finite number of variables. The sole property of a variable is its identity, that is, the fact that it is distinct from other variables. As a result, at a global level, all variables are interchangeable: if a theorem holds in the absence of hypotheses about any particular variable, then any renaming of it holds as well. We often make use of this fact. When proving a theorem

T

, we say that a hypothesis

H

may be assumed wihout loss of generality (w.l.o.g.) if the theorem

T

follows from the theorem

H \Rightarrow T

via a renaming argument, which is usually left implicit.

{\bar{z}}_{1}

and

{\bar{z}}_{2}

are sets of variables, we write

{\bar{z}}_{1} # {\bar{z}}_{2}

as a shorthand for

{\bar{z}}_{1} \cap {\bar{z}}_{2} = \emptyset

, and say that

{\bar{z}}_{1}

is fresh for

{\bar{z}}_{2}

(or vice-versa). We say that

\bar{z}

is fresh for

t

if and only if

\bar{z} # f v (t)

holds.

In this chapter, we work with several distinct varieties of names: program variables, memory locations, and type variables, the latter of which may be further divided into kinds. We draw names of different varieties from disjoint sets, each of which is infinite.

1.2 What is ML?

The name "ML" appeared during the late seventies. It then referred to a general-purpose programming language that was used as a meta-language (whence its name) within the theorem prover LCF (Gordon, Milner, and Wadsworth, 1979b). Since then, several new programming languages, each of which offers several different implementations, have drawn inspiration from it. So, what does "ML" stand for today?

For a semanticist, "ML" might stand for a programming language featuring first-class functions, data structures built out of products and sums, mutable
memory cells called references, exception handling, automatic memory management, and a call-by-value semantics. This view encompasses the Standard ML (Milner, Tofte, and Harper, 1990) and Caml (Leroy, 2000) families of programming languages. We refer to it as

M L

-the-programming-language.

For a type theorist, "ML" might stand for a particular breed of type systems, based on the simply-typed

λ

-calculus, but extended with a simple form of polymorphism introduced by let declarations. These type systems have decidable type inference; their type inference algorithms crucially rely on first-order unification and can be made efficient in practice. In addition to Standard ML and Caml, this view encompasses programming languages such as Haskell (Hudak, Peyton Jones, Wadler, Boutel, Fairbairn, Fasel, Guzman, Hammond, Hughes, Johnsson, Kieburtz, Nikhil, Partain, and Peterson, 1992) and Clean (Brus, van Eekelen, van Leer, and Plasmeijer, 1987), whose semantics is rather different-indeed, it is pure and lazy-but whose type system fits this description. We refer to it as

M L

-the-type-system. It is also referred to as Hindley and Milner's type discipline in the literature.

For us, "ML" might also stand for the particular programming language whose formal definition is given and studied in this chapter. It is a core calculus featuring first-class functions, let declarations, and constants. It is equipped with a call-by-value semantics. By customizing constants and their semantics, one may recover data structures, references, and more. We refer to this particular calculus as

M L

-the-calculus.

Why study ML-the-type-system today, such a long time after its initial discovery? One may think of at least two reasons.

First, its treatment in the literature is often cursory, because it is considered either as a simple extension of the simply-typed

λ

-calculus (TAPL Chapter 9) or as a subset of Girard and Reynolds' System F (TAPL Chapter 23). The former view is supported by the claim that the let construct, which distinguishes ML-the-type-system from the simply-typed

λ

-calculus, may be understood as a simple textual expansion facility. However, this view only tells part of the story, because it fails to give an account of the principal types property enjoyed by ML-the-type-system, leads to a naïve type inference algorithm whose time complexity is exponential, and breaks down when the language is extended with side effects, such as state or exceptions. The latter view is supported by the fact that every type derivation within ML-the-type-system is also a valid type derivation within an implicity-typed variant of System F. Such a view is correct, but again fails to give an account of type inference for ML-the-type-system, since type inference for System F is undecidable (Wells, 1999).

Second, existing accounts of type inference for ML-the-type-system (Milner, 1978; Damas and Milner, 1982; Tofte, 1988; Leroy, 1992; Lee and Yi, 1998;

Jones, 1999) usually involve heavy manipulations of type substitutions. Such an ubiquitous use of type substitutions is often quite obscure. Furthermore, actual implementations of the type inference algorithm do not explicitly manipulate substitutions; instead, they extend a standard first-order unification algorithm, where terms are updated in place as new equations are discovered (Huet, 1976). Thus, it is hard to tell, from these accounts, how to write an efficient type inference algorithm for ML-the-type-system. Yet, in spite of the increasing speed of computers, efficiency remains crucial when ML-thetype-system is extended with expensive features, such as Objective Caml's object types (Rémy and Vouillon, 1998) or polymorphic methods (Garrigue and Rémy, 1999).

For these reasons, we believe it is worth giving an account of ML-the-typesystem that focuses on type inference and strives to be at once elegant and faithful to an efficient implementation. To achieve these goals, we forego type substitutions and instead put emphasis on constraints, which offer a number of advantanges. First, constraints allow a modular presentation of type inference as the combination of a constraint generator and a constraint solver. Such a decomposition allows reasoning separately about when a program is correct, on the one hand, and how to check whether it is correct, on the other hand. It has long been standard in the setting of the simply-typed

λ

calculus (TAPL Chapter 22), but, to the best of our knowledge, has never been proposed for ML-the-type-system. Second, it is often natural to define and implement the solver as a constraint rewriting system. Then, the constraint language allows reasoning not only about correctness-is every rewriting step meaning-preserving?-but also about low-level implementation details, since constraints are the data structures manipulated throughout the type inference process. For instance, describing unification in terms of multiequations (Jouannaud and Kirchner, 1991) allows reasoning about the sharing of nodes in memory, which a substitution-based approach cannot account for. Last, constraints are more general than type substitutions, and allow describing many extensions of ML-the-type-system, among which extensions with recursive types, rows, subtyping, first-order unification under a mixed prefix, and more.

Before delving into the details of this new presentation of ML-the-typesystem, however, it is worth recalling its standard definition. Thus, in what follows, we first define the syntax and operational semantics of the programming language ML-the-calculus, and equip it with a type system, known as Damas and Milner's type system.

Figure 1-1: Syntax of ML-the-calculus

ML-the-calculus

The syntax of ML-the-calculus is defined in Figure 1-1. It is made up of several syntactic categories.

Identifiers group several kinds of names that may be referenced in a program: variables, memory locations, and constants. We let

x

and

y

range over identifiers. Variables-sometimes called program variables to avoid ambiguity — are names that may be bound to values using

λ

or let binding forms; in other words, they are names for function parameters or local definitions. We let

z

and

f

range over program variables. We sometimes write _ for a program variable that does not occur free within its scope: for instance,

λ_{_.t stands for} λ

z.t, provided

z

is fresh for

t

. Memory locations are names that represent memory addresses. By convention, memory locations never appear in source programs, that is, programs that are submitted to a compiler. They only appear during execution, when new memory blocks are allocated. Constants are fixed names for primitive values and operations, such as integer literals and integer arithmetic operations. Constants are elements of a finite or infinite set

Q

. They are never subject to

α

-conversion. Program variables, memory locations, and constants belong to distinct syntactic classes and may never be confused.

The set of constants

Q

is kept abstract, so most of our development is independent of its concrete definition. We assume that every constant

c

has a nonnegative integer arity

a (c)

. We further assume that

Q

is partitioned into subsets of constructors

Q^{+}

and destructors

Q^{-}

. Constructors and destructors differ in that the former are used to form values, while the latter are used to
operate on values.

1.2.1 ExAmple [IntEgERs]: For every integer

n

, one may introduce a nullary constructor

\hat{n}

. In addition, one may introduce a binary destructor

\hat{+}

, whose applications are written infix, so

t_{1} \hat{+} t_{2}

stands for the double application

\hat{+} t_{1} t_{2}

of the destructor

\hat{+}

to the expressions

t_{1}

and

t_{2}

Expressions - also known as program terms or programs - are the main syntactic category. Indeed, unlike procedural languages such as

C

and Java, functional languages, including ML-the-programming-language, suppress the distinction between expressions and statements. Expressions include identifiers,

λ

-abstractions, applications, and local definitions. The

λ

-abstraction

λ

z.t represents the function of one parameter named

z

whose result is the expression

t

, or, in other words, the function that maps

z

t

. Note that the variable

z

is bound within the term

t

, so (for instance)

λ z_{1} \cdot z_{1}

and

λ z_{2} \cdot z_{2}

are the same object. The application

t_{1} t_{2}

represents the result of calling the function

t_{1}

with actual parameter

t_{2}

, or, in other words, the result of applying

t_{1}

t_{2}

. Application is left-associative, that is,

t_{1} t_{2} t_{3}

stands for

(t_{1} t_{2}) t_{3}

. The construct let

z = t_{1}

t_{2}

represents the result of evaluating

t_{2}

after binding the variable

z

t_{1}

. Note that the variable

z

is bound within

t_{2}

, but not within

t_{1}

, so for instance let

z_{1} = z_{1}

z_{1}

and let

z_{2} = z_{1}

z_{2}

are the same object. The construct let

z = t_{1}

t_{2}

has the same meaning as

(λ z . t_{2}) t_{1}

, but is dealt with in a more flexible way by ML-the-type-system. To sum up, the syntax of ML-the-calculus is that of the pure

λ

-calculus, extended with memory locations, constants, and the let construct.

Values form a subset of expressions. They are expressions whose evaluation is completed. Values include identifiers,

λ

-abstractions, and applications of constants, of the form

c v_{1} \dots v_{k}

, where

k

does not exceed

c

's arity if

c

is a constructor, and

k

is smaller than c's arity if

c

is a destructor. In what follows, we are often interested in closed values, that is, values that do not contain any free program variables. We use the meta-variables

v

and

w

for values.

1.2.2 Example: The integer literals

\dots, \hat{- 1}, \hat{0}, \hat{1}, \dots

are nullary constructors, so they are values. Integer addition

\hat{+}

is a binary destructor, so it is a value, and so is every partial application

\hat{+} v

. Thus, both

\hat{+} \hat{1}

and

\hat{+} \hat{+}

are values. An application of

\hat{+}

to two values, such as

\hat{2} \hat{+} \hat{2}

, is not a value.

1.2.3 EXAmple [Pairs]: Let

(\cdot, \cdot)

be a binary constructor. If

t_{1}

are

t_{2}

are expressions, then the double application

(\cdot, \cdot) t_{1} t_{2}

may be called the pair of

t_{1}

and

t_{2}

, and may be written

(t_{1}, t_{2})

. By the definition above,

(t_{1}, t_{2})

is a value if and only if

t_{1}

and

t_{2}

are both values.

Stores are finite mappings from memory locations to closed values. A store

μ

represents what is usually called a heap, that is, a collection of data structures,
each of which is allocated at a particular address in memory and may contain pointers to other elements of the heap. ML-the-programming-language allows overwriting the contents of an existing memory block-an operation sometimes referred to as a side effect. In the operational semantics, this effect is achieved by mapping an existing memory location to a new value. We write

\emptyset

for the empty store. We write

μ [m \mapsto v]

for the store that maps

m

v

and otherwise coincides with

μ

. When

μ

and

μ^{'}

have disjoint domains, we write

μ μ^{'}

for their union. We write

dom (μ)

for the domain of

μ

and range

(μ)

for the set of memory locations that appear in its codomain.

The operational semantics of a purely functional language, such as the pure

λ

-calculus, may be defined as a rewriting system on expressions. Because MLthe-calculus has side effects, however, we define its operational semantics as a rewriting system on configurations. A configuration

t / μ

is a pair of an expression

t

and a store

μ

. The memory locations in the domain of

μ

are considered bound within

t / μ

, so (for instance)

m_{1} / (m_{1} \mapsto \hat{0})

and

m_{2} / (m_{2} \mapsto \hat{0})

are the same object. In what follows, we are often interested in closed configurations, that is, configurations

t / μ

such that

t

has no free program variables and every memory location that appears within

t

or within the range of

μ

is in the domain of

μ

. If

t

is a source program, its evaluation begins within an empty store-that is, with the configuration

t / \emptyset

. Because, by convention, source programs do not contain memory locations, this is a closed configuration. Furthermore, we shall see that all reducts of a closed configuration are closed as well. Please note that, instead of separating expressions and stores, it is possible to make store fragments part of the syntax of expressions; this idea, proposed in (Crank and Felleisen, 1991), is reminiscent of the encoding of reference cells in process calculi (Turner, 1995; Fournet and Gonthier, 1996).

A context is an expression where a single subexpression has been replaced with a hole, written [. Evaluation contexts form a strict subset of contexts. In an evaluation context, the hole is meant to highlight a point in the program where it is valid to apply a reduction rule. Thus, the definition of evaluation contexts determines a reduction strategy: it tells where and in what order reduction steps may occur. For instance, the fact that

λ z

]

is not an evaluation context means that the body of a function is never evaluated-that is, not until the function is applied, see R-BETA below. The fact that

t E

is an evaluation context only if

t

is a value means that, to evaluate an application

t_{1} t_{2}

, one should fully evaluate

t_{1}

before attempting to evaluate

t_{2}

. More generally, in the case of a multiple application, it means that arguments should be evaluated from left to right. Of course, other choices could be made: for instance, defining

E ::= \dots | t E | E v ∣ \dots

would enforce a right-to-left evaluation order, while defining

E ::= \dots ∣

E | E t | \dots

would leave the evaluation order unspecified, effectively allowing reduction to alternate between

let

z = v

t ⟶ [z \mapsto v] t

(R-BETA)

(R-LET)

t / μ ⟶ t^{'} / μ^{'}

dom (μ^{''}) # dom (μ^{'})

\frac{range (μ^{''}) # dom (μ^{'} ∖ μ)}{t / μ μ^{''} ⟶ t^{'} / μ^{'} μ^{''}}

(R-ExtEnd)

\frac{t / μ \overset{δ}{\to} t^{'} / μ^{'}}{t / μ ⟶ t^{'} / μ^{'}}

(R-Delta)

\frac{t / μ ⟶ t^{'} / μ^{'}}{E [t] / μ ⟶ E [t^{'}] / μ^{'}}

(R-CONTEXT)

Figure 1-2: Semantics of ML-the-calculus

both subexpressions, and making evaluation nondeterministic. The fact that let

z = v

E

is not an evaluation context means that the body of a local definition is never evaluated - that is, not until the definition itself is reduced, see R-LET below. We write

E [t]

for the expression obtained by replacing the hole in

E

with the expression

t

Figure 1-2 defines first a relation

⟶

between configurations, then a relation

⟶

between closed configurations. If

t / μ ⟶ t^{'} / μ^{'}

t / μ ⟶ t^{'} / μ^{'}

holds, then we say that the configuration

t / μ

reduces to the configuration

t^{'} / μ^{'}

; the ambiguity involved in this definition is benign. If

t / μ ⟶ t^{'} / μ

holds for every store

μ

, then we write

t ⟶ t^{'}

and say that the reduction is pure.

The key reduction rule is

R

-BETA, which states that a function application

(λ z . t) v

reduces to the function body, namely

t

, where every occurrence of the formal argument

z

has been replaced with the actual argument

v

. The

λ

construct, which prevented the function body t from being evaluated, disappears, so the new term may (in general) be further reduced. Because ML-the-calculus adopts a call-by-value strategy, rule R-BETA is applicable only if the actual argument is a value v. In other words, a function cannot be invoked until its actual argument has been fully evaluated. Rule R-LET is very similar to

R

-BETA. Indeed, it specifies that let

z = v

t

has the same behavior, with respect to reduction, as

(λ z . t) v

. We remark that substitution of a value for a program variable throughout a term is expensive, so R-BETA and R-LET are never implemented literally: they are only a simple specification. Actual implementations usually employ runtime environments, which may be understood as a form of explicit substitutions (Abadi, Cardelli, Curien, and Lévy, 1991). Please note that our choice of a call-by-value reduction strategy is fairly arbitrary, and has essentially no impact on the type system; the programming language Haskell (Hudak, Peyton Jones, Wadler, Boutel, Fairbairn, Fasel, Guzman, Hammond, Hughes, Johnsson, Kieburtz,

Nikhil, Partain, and Peterson, 1992), whose reduction strategy is known as lazy or call-by-need, also relies on Hindley and Milner's type discipline.

Rule R-DELTA describes the semantics of constants. It merely states that a certain relation

\overset{δ}{\to}

is a subset of

⟶

. Of course, since the set of constants is unspecified, the relation

\overset{δ}{\to}

must be kept abstract as well. We require that, if

t / μ \overset{δ}{\to} t^{'} / μ^{'}

holds, then

(i)

t

is of the form

c v_{1} \dots v_{n}

, where

c

is a destructor of arity

n

; and

(ii)

dom (μ)

is a subset of

dom (μ^{'})

Condition (i) ensures that

δ

-reduction concerns full applications of destructors only, and that these are evaluated in accordance with the call-by-value strategy. Condition (ii) ensures that

δ

-reduction may allocate new memory locations, but not deallocate existing locations. In particular, a "garbage collection" operator, which destroys unreachable memory cells, cannot be made available as a constant. Doing so would not make much sense anyway in the presence of R-EXTEND, which states that any valid reduction is also valid in a larger store. Condition (ii) allows proving that, if

t / μ

reduces to

t^{'} / μ^{'}

, then

dom (μ)

is a subset of

dom (μ^{'})

; this is left as an exercise to the reader.

1.2.4 Example [Integers, Continued]: The operational semantics of integer addition may be defined as follows:

\begin{matrix} (R-ADD) & {\hat{k}}_{1} \hat{+} {\hat{k}}_{2} \overset{δ}{\to} \hat{k_{1} + k_{2}} \end{matrix}

The left-hand term is the double application

\hat{+} {\hat{k}}_{1} {\hat{k}}_{2}

, while the right-hand term is the integer literal

\hat{k}

, where

k

is the sum of

k_{1}

and

k_{2}

. The distinction between object level and meta level (that is, between

\hat{k}

and

k

) is needed here to avoid ambiguity.

1.2.5 Example [Pairs, continued]: In addition to the pair constructor defined in Example 1.2.3, we may introduce two destructors

π_{1}

and

π_{2}

of arity 1 . We may define their operational semantics as follows, for

i \in {1, 2}

\begin{matrix} (R-PROJ) & π_{i} (v_{1}, v_{2}) \overset{δ}{\to} v_{i} \end{matrix}

Thus, our treatment of constants is general enough to account for pair construction and destruction; we need not build these features explicitly into the language.

1.2.6 Exercise [Booleans, Recommended,

⋆ ⋆

]: Let true and false be nullary constructors. Let if be a ternary destructor. Extend the operational semantics with

\begin{matrix} (R-TRUE) & if true v_{1} v_{2} \overset{δ}{\to} v_{1} \end{matrix}

\begin{matrix} (R-FALSE) & if false v_{1} v_{2} \overset{δ}{\to} v_{2} \end{matrix}

Let us use the syntactic sugar if

t_{0}

then

t_{1}

else

t_{2}

for the triple application of if

t_{0} t_{1} t_{2}

. Explain why these definitions do not quite provide the expected behavior. Without modifying the semantics of if, suggest a new definition of the syntactic sugar if

t_{0}

then

t_{1}

else

t_{2}

that corrects the problem.

1.2.7 Example [Sums]: Booleans may in fact be viewed as a special case of the more general concept of sum. Let

i n j_{1}

and

i n j_{2}

be unary constructors, called respectively left and right injections. Let case be a ternary destructor, whose semantics is defined as follows, for

i \in {1, 2}

\begin{matrix} (R-CASE) & case ({i n j}_{i} v) v_{1} v_{2} \overset{δ}{\to} v_{i} v \end{matrix}

Here, the value

i n j_{i} v

is being scrutinized, while the values

v_{1}

and

v_{2}

, which are typically functions, represent the two arms of a standard case construct. The rule selects an appropriate arm (here,

v_{i}

) based on whether the value under scrutiny was formed using a left or right injection. The arm

v_{i}

is executed and given access to the data carried by the injection (here, v).

1.2.8 EXERcISE

[⋆, ↛]

: Explain how to encode true,

f

al se and the if construct in terms of sums. Check that the behavior of R-TRUE and R-FALSE is properly emulated.

1.2.9 ExAmple [REFEREnces]: Let ref and ! be unary destructors. Let

:=

be a binary destructor. We write

t_{1} := t_{2}

for the double application

:= t_{1} t_{2}

. Define the operational semantics of these three destructors as follows:

\begin{matrix} (R-AssiGN) & \begin{array}{rr} ref v / \emptyset \overset{δ}{\to} m / (m \mapsto v) if m is fresh for v & (R - R E F) \\ ! m / (m \mapsto v) \overset{δ}{\to} v / (m \mapsto v) & (R-DEREF) \\ m := v / (m \mapsto v_{0}) \overset{δ}{\to} v / (m \mapsto v) & (R-AssiGN) \end{array} \end{matrix}

According to R-REF, evaluating ref

v

allocates a fresh memory location

m

and binds

v

to it. Because configurations are considered equal up to

α -

conversion of memory locations, the choice of the name

m

is irrelevant, provided it is chosen fresh for

v

, so as to prevent inadvertent capture of the memory locations that appear free within v. By R-DEREF, evaluating

! m

returns the value bound to the memory location

m

within the current store. By

R

-Assign, evaluating

m := v

discards the value

v_{0}

currently bound to

m

and produces a new store where

m

is bound to v. Here, the value returned by the assignment

m := v

v

itself; in ML-the-programming-language, it is usually a nullary constructor (), pronounced unit.

1.2.10 EXAmple [REcursion]: Let fix be a binary destructor, whose operational semantics is:

\begin{matrix} (R-FIX) & {f i x v}_{1} v_{2} \overset{δ}{\to} v_{1} ({f i x}_{1}) v_{2} \end{matrix}

fix is a fixpoint combinator: it effectively allows recursive definitions of functions. Indeed, the construct letrec

f = λ

_{1}

t_{2}

provided by MLthe-programming-language may be viewed as syntactic sugar for let

f =

fix

(λ f . λ z . t_{1})

t_{2}

Rule R-CONTEXT completes the definition of the operational semantics by defining

⟶

, a relation between closed configurations, in terms of

⟶

. The rule states that reduction may take place not only at the term's root, but also deep inside it, provided the path from the root to the point where reduction occurs forms an evaluation context. This is how evaluation contexts determine an evaluation strategy. As a purely technical point, because

⟶

relates closed configurations only, we do not need to require that the memory locations in

dom (μ^{'} ∖ μ)

be fresh for

E

: indeed, every memory location that appears within

E

must be a member of

dom (μ)

1.2.11 Exercise

[⋆ ⋆ ⋆

, Recommended,

\to

]

: Assuming the availability of Booleans and conditionals, integer literals, subtraction, multiplication, integer comparison, and a fixpoint combinator, most of which were defined in previous examples, define a function that computes the factorial of its integer argument, and apply it to

\hat{3}

. Determine, step by step, how this expression reduces to a value.

It is straightforward to check that, if

t / μ

reduces to

t^{'} / μ^{'}

, then

t

is not a value. In other words, values are irreducible: they represent a completed computation. The proof is left as an exercise to the reader. The converse, however, does not hold: if

t / μ

is irreducible with respect to

⟶

, then

t

is not necessarily a value. In that case, the configuration

t / μ

is said to be stuck. It represents a runtime error, that is, a situation that does not allow computation to proceed, yet is not considered a valid outcome. A closed source program

t

is said to go wrong if and only if the configuration

t / \emptyset

reduces to a stuck configuration.

1.2.12 ExAmple: Runtime errors typically arise when destructors are applied to arguments of an unexpected nature. For instance, the expressions

+ 1 m

and

π_{1} 2

and

! 3

are stuck, regardless of the current store. The program let

z =

\hat{+} \hat{+}

z

is not stuck, because

\hat{+} \hat{+}

is a value. However, its reduct through

R

-LET is

\hat{+} \hat{+}

, which is stuck, so this program goes wrong. The primary purpose of type systems is to prevent such situations from arising.

1.2.13 Example: The configuration

! m / μ

is stuck if

m

is not in the domain of

μ

. In that case, however,

! m / μ

is not closed. Because we consider

⟶

as a relation between closed configurations only, this situation cannot arise. In other
words, the semantics of ML-the-calculus never allows the creation of dangling pointers. As a result, no particular precautions need be taken to guard against them. Several strongly typed programming languages do nevertheless allow dangling pointers in a controlled fashion (Tofte and Talpin, 1997; Crary, Walker, and Morrisett, 1999b; DeLine and Fähndrich, 2001; Grossman, Morrisett, Jim, Hicks, Wang, and Cheney, 2002a).

Damas and Milner's type system

ML-the-type-system was originally defined by Milner (1978). Here, we reproduce the definition given a few years later by Damas and Milner (1982), which is written in a more standard style: typing judgements are defined inductively by a collection of typing rules. We refer to this type system as DM.

To begin, we must define types. In DM, like in the simply-typed

λ

-calculus, types are first-order terms built out of type constructors and type variables. We begin with several considerations concerning the specification of type constructors.

First, we do not wish to fix the set of type constructors. Certainly, since MLthe-calculus has functions, we need to be able to form an arrow type

T \to T^{'}

out of arbitrary types

T

and

T^{'}

; that is, we need a binary type constructor

\to

. However, because ML-the-calculus includes an unspecified set of constants, we cannot say much else in general. If constants include integer literals and integer operations, as in Example 1.2.1, then a nullary type constructor int is needed; if they include pair construction and destruction, as in Examples 1.2.3 and 1.2.5, then a binary type constructor

\times

is needed; and so on.

Second, it is common to refer to the parameters of a type constructor by position, that is, by numeric index. For instance, when one writes

T \to T^{'}

, it is understood that the type constructor

\to

has arity 2, that

T

is its first parameter, known as its domain, and that

T^{'}

is its second parameter, known as its codomain. Here, however, we refer to parameters by names, known as directions. For instance, we define two directions domain and codomain and let the type constructor

\to

have arity

{

domain, codomain

}

. The extra generality afforded by directions is exploited in the definition of nonstructural subtyping (Example 1.3.9) and in the definition of rows (Section 1.11).

Last, we allow types to be classified using kinds. As a result, every type constructor must come not only with an arity, but with a richer signature, which describes the kinds of the types to which it is applicable and the kind of the type that it produces. A distinguished kind

⋆

is associated with "normal" types, that is, types that are directly ascribed to expressions and values. For instance, the signature of the type constructor

\to

{

domain

\mapsto ⋆

, codomain

\mapsto ⋆} \Rightarrow ⋆

, because it is applicable to two "normal" types and produces a "normal" type.

Introducing kinds other than

⋆

allows viewing some terms as ill-formed types; this is illustrated, for instance, in Section 1.11. In the simplest case, however,

⋆

is really the only kind, so the signature of a type constructor is nothing but its arity (a set of directions), and every term is a well-formed type, provided every application of a type constructor respects its arity.

1.2.14 Definition: Let

d

range over a finite or denumerable set of directions. Let

κ

range over a finite or denumerable set of kinds. Let

⋆

be a distinguished kind. Let

K

range over partial mappings from directions to kinds. Let

F

range over a finite or denumerable set of type constructors, each of which has a signature of the form

K \Rightarrow κ

. The domain of

K

is referred to as the arity of

F

, while

κ

is referred to as its image kind. We write

κ

instead of

K \Rightarrow κ

when

K

is empty. Let

\to

be a type constructor of signature

{

domain

\mapsto ⋆

, codomain

\mapsto ⋆} \Rightarrow ⋆

The type constructors and their signatures collectively form a signature

S

. In the following, we assume that a fixed signature

S

is given and that every type constructor in it has finite arity, so as to ensure that types are machine representable. However, in Section 1.11, we shall explicitly work with several distinct signatures, some of which involve type constructors of denumerable arity.

A type variable is a name that is used to stand for a type. For simplicity, we assume that every type variable is branded with a kind, or, in other words, that type variables of distinct kinds are drawn from disjoint sets. Each of these sets of type variables is individually subject to

α

-conversion: that is, renamings must preserve kinds. Attaching kinds to type variables is only a technical convenience: in practice, every operation performed during type inference preserves the property that every type is well-kinded, so it is not necessary to keep track of the kind of every type variable. It is only necessary to check that all types supplied by the user, within type declarations, type annotations, or module interfaces, are well-kinded.

1.2.15 Definition: For every kind

κ

, let

V_{κ}

be a disjoint, denumerable set of type variables. Let

X, Y

, and

Z

range over the set

V

of all type variables. Let

\bar{X}

and

\bar{Y}

range over finite sets of type variables. We write

\bar{X} \bar{Y}

for the set

\bar{X} \cup \bar{Y}

and often write

X

for the singleton set

{X}

. We write

f t v (o)

for the set of free type variables of an object

o

The set of types, ranged over by

T

, is the free many-kinded term algebra that arises out of the type constructors and type variables.

1.2.16 Definition: A type of kind

κ

is either a member of

V_{κ}

, or a term of the form

F {d_{1} \mapsto T_{1}, \dots, d_{n} \mapsto T_{n}}

, where

F

has signature

{d_{1} \mapsto κ_{1}, \dots, d_{n} \mapsto κ_{n}} \Rightarrow

κ

and

T_{1}, \dots, T_{n}

are types of kind

κ_{1}, \dots, κ_{n}

, respectively.

As a notational convention, we assume that, for every type constructor

F

, the directions that form the arity of

F

are implicitly ordered, so that we may say that

F

has signature

κ_{1} \otimes \dots \otimes κ_{n} \Rightarrow κ

and employ the syntax

F T_{1} \dots T_{n}

for applications of

F

. Applications of the type constructor

\to

are written infix and associate to the right, so

T \to T^{'} \to T^{''}

stands for

T \to (T^{'} \to T^{''})

In order to give meaning to the free type variables of a type, or, more generally, of a typing judgement, traditional presentations of ML-the-typesystem, including Damas and Milner's, employ type substitutions. Most of our presentation avoids substitutions and uses constraints instead. However, we do need substitutions on a few occasions, especially when relating our presentation to Damas and Milner's.

1.2.17 Definition: A type substitution

θ

is a total, kind-preserving mapping of type variables to types that is the identity everywhere but on a finite subset of

V

, which we call the domain of

θ

and write

dom (θ)

. The range of

θ

, which we write range

(θ)

, is the set

ftv (θ (dom (θ)))

. A type substitution may naturally be viewed as a total, kind-preserving mapping of types to types. In the following, we write

\bar{X} # θ

for

\bar{X} # (dom (θ) \cup

range

(θ))

. We write

θ ∖ \bar{X}

for the restriction of

θ

outside

\bar{X}

, that is, the restriction of

θ

V ∖ \bar{X}

. We sometimes let

φ

denote a type substitution.

\vec{X}

and

\vec{T}

are respectively a vector of distinct type variables and a vector of types of the same (finite) length, such that, for every index

i, x_{i}

and

T_{i}

have the same kind, then

[\vec{X} \mapsto \vec{T}]

denotes the substitution that maps

X_{i}

T_{i}

for every index

i

. The domain of

[\vec{X} \mapsto \vec{T}]

is a subset of

\bar{X}

, the set underlying the vector

\vec{X}

. Its range is a subset of

f t v (\bar{T})

, where

\bar{T}

is the set underlying the vector

\vec{T}

. Every substitution

θ

may be written under the form

[\vec{X} \mapsto \vec{T}]

, where

\bar{X} = dom (θ)

. Then,

θ

is idempotent if and only if

\bar{X} # f t v (\bar{T})

holds.

As pointed out earlier, types are first-order terms; that is, in the grammar of types, none of the productions binds a type variable. As a result, every type variable that appears within a type

T

appears free within

T

. This situation is identical to that of the simply-typed

λ

-calculus. Things become more interesting when we introduce type schemes. As its name implies, a type scheme may describe an entire family of types; this effect is achieved via universal quantification over a set of type variables.

1.2.18 Definition: A type scheme

S

is an object of the form

\forall \bar{X}

T

, where

T

is a type of kind

⋆

and the type variables

\bar{X}

are considered bound within

T

One may view the type

T

as the trivial type scheme

\forall \emptyset

T

, where no type variables are universally quantified, so types may be viewed as a subset of type schemes. The type scheme

\forall \bar{X} . T

may be viewed as a finite way of describing the possibly infinite family of types of the form

[\vec{X} \mapsto \vec{T}] T

, where

\vec{T}

is arbitrary.

Γ (x) = S

(D M - V A R)

Γ ⊢ t_{1} : s

Γ; z : S ⊢ t_{2} : T

(DM-LET)

\bar{Γ ⊢ x : S}

\bar{Γ ⊢ let z = t_{1} in t_{2} : T}

Γ; z : T ⊢ t : T^{'}

(D M - A B S)

Γ ⊢ t : T

\bar{x} # f t v (Γ)

(DM-GEN)

\bar{Γ ⊢ λ z . t : T \to T^{'}}

{

Γ ⊢ t : \forall X . T

Γ ⊢ t : \forall \bar{X} . T

Γ ⊢ t : [\vec{X} \mapsto \vec{T}] T

}

(DM-APP)

(DM-INST)

Γ ⊢ t_{1} t_{2} : T^{'}

Figure 1-3: Typing rules for DM

Such types are called instances of the type scheme

\forall \bar{X}

.T. Note that, throughout most of this chapter, we work with constrained type schemes, a generalization of DM type schemes (Definition 1.3.2).

Typing environments, or environments for short, are used to collect assumptions about an expression's free identifiers.

1.2.19 Definition: An environment

Γ

is a finite ordered sequence of pairs of a program identifier and a type scheme. We write

\emptyset

for the empty environment and ; for the concatenation of environments. An environment may be viewed as a finite mapping from program identifiers to type schemes by letting

Γ (x) = S

if and only if

Γ

is of the form

Γ_{1}; x : S; Γ_{2}

, where

Γ_{2}

contains no assumption about

x

. The set of defined program identifiers of an environment

Γ

, written

d p i (Γ)

, is defined by

d p i (\emptyset) = \emptyset

and

d p i (Γ; x : S) = d p i (Γ) \cup {x}

To complete the definition of Damas and Milner's type system, there remains to define typing judgements. A typing judgement takes the form

Γ ⊢ t : S

, where

t

is an expression of interest,

Γ

is an environment, which typically contains assumptions about t's free program identifiers, and

S

is a type scheme. Such a judgement may be read: under assumptions

Γ

, the expression

t

has the type scheme

S

. By abuse of language, it is sometimes said that

t

has type

S

. A typing judgement is valid (or holds) if and only if it may be derived using the rules that appear in Figure 1-3. An expression t is well-typed within the environment

Γ

if and only if some judgement of the form

Γ ⊢ t : S

holds; it is ill-typed within

Γ

otherwise.

Rule DM-VAR allows fetching a type scheme for an identifier

x

from the environment. It is equally applicable to program variables, memory locations, and constants. If no assumption concerning

x

appears in the environment

Γ

, then the rule isn't applicable. In that case, the expression

x

is ill-typed within

Γ

- can you prove it? Assumptions about constants are usually collected in
a so-called initial environment

Γ_{0}

. It is the environment under which closed programs are typechecked, so every subexpression is typechecked under some extension

Γ

Γ_{0}

. Of course, the type schemes assigned by

Γ_{0}

to constants must be consistent with their operational semantics; we say more about this later (Section 1.7). Rule DM-ABS specifies how to typecheck a

λ

-abstraction

λ

z.t. Its premise requires the body of the function, namely

t

, to be well-typed under an extra assumption, which causes all free occurrences of

z

within

t

to receive a common type

T

. Its conclusion forms the arrow type

T \to T^{'}

out of the types of the function's formal parameter, namely

T

, and result, namely

T^{'}

. It is worth noting that this rule always augments the environment with a type

T

- recall that, by convention, types form a subset of type schemesbut never with a nontrivial type scheme. DM-APP states that the type of a function application is the codomain of the function's type, provided that the domain of the function's type is a valid type for the actual argument. DMLET closely mirrors the operational semantics: whereas the semantics of the local definition let

z = t_{1}

t_{2}

is to augment the runtime environment by binding

z

to the value of

t_{1}

prior to evaluating

t_{2}

, the effect of DM-LET is to augment the typing environment by binding

z

to a type scheme for

t_{1}

prior to typechecking

t_{2}

. DM-GEN turns a type into a type scheme by universally quantifying over a set of type variables that do not appear free in the environment; this restriction is discussed in Example 1.2.20 below. DMINST, on the contrary, turns a type scheme into one of its instances, which may be chosen arbitrarily. These two operations are referred to as generalization and instantiation. The notion of type scheme and the rules DM-GEN and DMINsT are characteristic of ML-the-type-system: they distinguish it from the simply-typed

λ

-calculus.

1.2.20 EXAmPLE: It is unsound to allow generalizing type variables that appear free in the environment. For instance, consider the typing judgement

z : X ⊢ z

: X (1), which, according to DM-VAR, is valid. Applying an unrestricted version of DM-GEN to it, we obtain

z : X ⊢ z : \forall X . X

(2), whence, by DM-INST, z : X

⊢

z : Y (3). By DM-ABS and DM-GEN, we then have

\emptyset ⊢ λ z . z : \forall X Y . X \to Y

. In other words, the identity function has unrelated argument and result types! Then, the expression

(λ z . z) \hat{0} \hat{0}

, which reduces to the stuck expression

\hat{0} \hat{0}

, has type scheme

\forall z . z

. So, well-typed programs may cause runtime errors: the type system is unsound.

What happened? It is clear that the judgement (1) is correct only because the type assigned to

z

is the same in its assumption and in its right-hand side. For the same reason, the judgements (2) and (3)-the former of which may be written

z : X ⊢ z : \forall Y . Y

-are incorrect. Indeed, such judgements defeat the very purpose of environments, since they disregard their assumption.

By universally quantifying over

x

in the right-hand side only, we break the connection between occurrences of

X

in the assumption, which remain free, and occurrences in the right-hand side, which become bound. This is correct only if there are in fact no free occurrences of

X

in the assumption.

It is a key feature of ML-the-type-system that DM-ABS may only introduce a type

T

, rather than a type scheme, into the environment. Indeed, this allows the rule's conclusion to form the arrow type

T \to T^{'}

. If instead the rule were to introduce the assumption

z : S

into the environment, then its conclusion would have to form

S \to T^{'}

, which is not a well-formed type. In other words, this restriction is necessary to preserve the stratification between types and type schemes. If we were to remove this stratification, thus allowing universal quantifiers to appear deep inside types, we would obtain an implicitly-typed version of System F (TAPL Chapter 23). Type inference for System F is undecidable (Wells, 1999), while type inference for ML-the-type-system is decidable, as we show later, so this design choice has a rather drastic impact.

1.2.21 Exercise [

⋆

, Recommended]: Build a type derivation for the expression

λ z_{1}

. let

z_{2} = z_{1}

z_{2}

within DM.

1.2.22 Exercise

[⋆

, Recommended]: Let int be a nullary type constructor of signature

⋆

. Let

Γ_{0}

consist of the bindings

\hat{+} :

int

\to

int

\to

int and

\hat{k} :

int, for every integer

k

. Can you find derivations of the following valid typing judgements? Which of these judgements are valid in the simply-typed

λ

-calculus, where let

z = t_{1}

t_{2}

is syntactic sugar for

(λ z . t_{2}) t_{1}

\begin{matrix} Γ_{0} ⊢ λ z . z : int \to int \\ Γ_{0} ⊢ λ z . z : \forall x . x \to x \\ Γ_{0} ⊢ et f = λ z . z \hat{+} \hat{1} in f \hat{2} : int \\ Γ_{0} ⊢ let f = λ z . z inf f \hat{2} : int \end{matrix}

Show that the expressions

\hat{1} \hat{2}

and

λ f

.(f

f

) are ill-typed within

Γ_{0}

. Could these expressions be well-typed in a more powerful type system?

1.2.23 EXERCISE

[⋆ ⋆ ⋆]

: In fact, the rules shown in Figure 1-3 are not exactly Damas and Milner's original rules. In (Damas and Milner, 1982), the generalization and instantiation rules are:

\begin{matrix} (DM-GEN') & \frac{Γ ⊢ t : S X \notin f t v (Γ)}{Γ ⊢ t : \forall X . S} \\ (DM-INST') & \frac{Γ ⊢ t : \forall \bar{X} . T \bar{Y} # f t v (\forall \bar{X} . T)}{Γ ⊢ t : \forall \bar{Y} . [\vec{X} \mapsto \vec{T}] T} \end{matrix}

where

\forall

X.S stands for

\forall X \bar{X}

.T if

S

stands for

\forall \bar{X}

.T. Show that the combination of DM-GEN' and DM-INST' is equivalent to the combination of DM-GEN and DM-INST.

DM enjoys a number of nice theoretical properties, which have practical implications. First, under suitable hypotheses about the semantics of constants, about the type schemes that they receive in the initial environment, and - in the presence of side effects - under a slight restriction of the syntax of let constructs, it is possible to show that the type system is sound: that is, well-typed (closed) programs do not go wrong. This essential property ensures that programs that are accepted by the typechecker may be compiled without runtime checks. Furthermore, it is possible to show that there exists an algorithm that, given a (closed) environment

Γ

and a program

t

, tells whether

t

is well-typed with respect to

Γ

, and if so, produces a principal type scheme

S

. A principal type scheme is such that (i) it is valid, that is,

Γ ⊢ t : S

holds, and (ii) it is most general, that is, every judgement of the form

Γ ⊢ t : S^{'}

follows from

Γ ⊢ t : S

by DM-InsT and DM-GEN. (For the sake of simplicity, we have stated the properties of the type inference algorithm only in the case of a closed environment

Γ

; the specification is slightly heavier in the general case.) This implies that type inference is decidable: the compiler does not require expressions to be annotated with types. It also implies that, under a fixed environment

Γ

, all of the type information associated with an expression

t

may be summarized in the form of a single (principal) type scheme, which is very convenient.

Road map

Before proving the above claims, we first generalize our presentation by moving to a constraint-based setting. The necessary tools, namely the constraint language, its interpretation, and a number of constraint equivalence laws, are introduced in Section 1.3. In Section 1.4, we describe the standard constraintbased type system

HM (X)

(Odersky, Sulzmann, and Wehr, 1999a; Sulzmann, Müller, and Zenger, 1999; Sulzmann, 2000). We prove that, when constraints are made up of equations between free, finite terms,

HM (X)

is a reformulation of DM. In the presence of a more powerful constraint language,

HM (X)

is an extension of DM. In Section 1.5, we propose an original reformulation of

HM (X)

, dubbed

PCB (X)

, whose distinctive feature is to exploit type scheme introduction and instantiation constraints. In Section 1.6, we show that, thanks to the extra expressive power afforded by these constraint forms, type inference may be viewed as a combination of constraint generation and constraint solving, as promised earlier. Indeed, we define a constraint generator and relate it with

PCB (X)

. Then, in Section 1.7, we give a type soundness
theorem. It is stated purely in terms of constraints, but-thanks to the results developed in the previous sections - applies equally to

PCB (X), HM (X)

, and DM.

Throughout this core material, the syntax and interpretation of constraints are left partly unspecified. Thus, the development is parameterized with respect to them-hence the unknown

X

in the names

HM (X)

and

PCB (X)

. We really describe a family of constraint-based type systems, all of which share a common constraint generator and a common type soundness proof. Constraint solving, however, cannot be independent of

X

: on the contrary, the design of an efficient solver is heavily dependent on the syntax and interpretation of constraints. In Section 1.8, we consider constraint solving in the particular case where constraints are made up of equations interpreted in a free tree model, and define a constraint solver on top of a standard first-order unification algorithm.

The remainder of this chapter deals with extensions of the framework. In Section 1.9, we explain how to extend ML-the-calculus with a number of features, including data structures, pattern matching, and type annotations. In Section 1.10, we extend the constraint language with universal quantification and describe a number of extra features that require this extension, including a different flavor of type annotations, polymorphic recursion, and first-class universal and existential types. Last, in Section 1.11, we extend the constraint language with rows and describe their applications, which include extensible variants and records.

1.3 Constraints

In this section, we define the syntax and logical meaning of constraints. Both are partly unspecified. Indeed, the set of type constructors (Definition 1.2.14) must contain at least the binary type constructor

\to

, but might contain more. Similarly, the syntax of constraints involves a set of so-called predicates on types, which we require to contain at least a binary subtyping predicate

\leq

, but might contain more. Furthermore, the logical interpretation of type constructors and of predicates is left almost entirely unspecified. This freedom allows reasoning not only about Damas and Milner's type system, but also about a family of constraint-based extensions of it.

Type constructors other than

\to

and predicates other than

\leq

will never explicitly appear in the definition of our constraint-based type systems, precisely because the definition is parametric with respect to them. They can (and usually do) appear in the type schemes assigned to constructors and destructors by the initial environment

Γ_{0}

The introduction of subtyping has little impact on the complexity of our

Figure 1-4: Syntax of type schemes and constraints

proofs, yet increases the framework's expressive power. When subtyping is not desired, we interpret the predicate

\leq

as equality.

Syntax

We now define the syntax of constrained type schemes and of constraints, and introduce some extra constraint forms as syntactic sugar.

1.3.1 Definition: Let

P

range over a finite or denumerable set of predicates, each of which has a signature of the form

κ_{1} \otimes \dots \otimes κ_{n} \Rightarrow \cdot

, where

n \geq 0

. Let

\leq

be a distinguished predicate of signature

⋆ \otimes ⋆ \Rightarrow ∙

1.3.2 Definition: The syntax of type schemes and constraints is given in Figure 14. It is further restricted by the following requirements. In the type scheme

\forall \bar{X} [C] . T

and in the constraint

x ⪯ T

, the type

T

must have kind

⋆

. In the constraint

P T_{1} \dots T_{n}

, the types

T_{1}, \dots, T_{n}

must have kind

κ_{1}, \dots, κ_{n}

, respectively, if

P

has signature

κ_{1} \otimes \dots \otimes κ_{n} \Rightarrow \cdot

. We write

\forall \bar{X}

.T for

\forall \bar{x} [

true].T, which allows viewing DM type schemes as a subset of constrained type schemes.

We write

T_{1} \leq T_{2}

for the binary predicate application

\leq T_{1} T_{2}

, and call it a subtyping constraint. By convention,

\exists

and def bind tighter than

\land

; that is,

\exists \bar{x} . C \land D

(\exists \bar{x} . C) \land D

and def

x : σ

C \land D

(def x : σ

C) \land D

. In

\forall \bar{x} [C] . T

, the type variables

\bar{X}

are bound within

C

and

T

. In

\exists \bar{X}

C

, the type variables

\bar{X}

are bound within

C

. The sets of free type variables of a type scheme

σ

and of a constraint

C

, written

f t v (σ)

and

f t v (C)

, respectively, are defined accordingly. In def

x : σ

C

, the identifier

x

is bound within

C

. The sets
of free program identifiers of a type scheme

σ

and of a constraint

C

, written

f p i (σ)

and

f p i (C)

, respectively, are defined accordingly. Please note that

x

occurs free in the constraint

x ⪯ T

We immediately introduce a number of derived constraint forms:

1.3.3 Definition: Let

σ

\forall \bar{X} [C]

.T. If

\bar{X} # ftv (T^{'})

holds, then

σ ⪯ T^{'}

(read:

T^{'}

is an instance of

σ)

stands for the constraint

\exists \bar{X}

(C \land T \leq T^{'})

. We write

\exists σ

(read:

σ

has an instance) for

\exists \bar{x} . C

and let

x : σ

C

for

\exists σ \land def x : σ

C

Constrained type schemes generalize Damas and Milner's type schemes, while our definition of instantiation constraints generalizes Damas and Milner's instance relation (Definition 1.2.18). Let us draw a comparison. First, Damas and Milner's instance relation yields a "yes/no" answer, and is purely syntactic: for instance, the type

Y \to Z

is not an instance of

\forall X

X \to X

in Damas and Milner's sense, because

Y

and

Z

are distinct type variables. In our presentation, on the other hand,

\forall X . X \to X ⪯ Y \to Z

is not an assertion; rather, it is a constraint, which by definition is

\exists X

. (true

\land X \to X \leq Y \to Z

). We later prove that it is equivalent to

\exists X

(Y \leq X \land X \leq Z)

and to

Y \leq Z

, or, if subtyping is interpreted as equality, to

Y = Z

. That is,

σ ⪯ T^{'}

represents a condition on (the types denoted by) the type variables in

f t v (σ, T^{'})

for

T^{'}

to be an instance of

σ

, in a logical, rather than purely syntactic, sense. Second, the definition of instantiation constraints involves subtyping, so as to ensure that any supertype of an instance of

σ

is again an instance of

σ

(see rule C-ExTrans in Figure 1-6 and Lemma 1.3.17). This is consistent with the purpose of subtyping, which is to allow supplying a subtype where a supertype is expected (TAPL Chapter 15). Third and last, every type scheme now carries a constraint. The constraint

C

, whose free type variables may or may not be members of

\bar{x}

, restricts the instances of the type scheme

\forall \bar{x} [C]

.T. This is expressed in the instantiation constraint

\exists \bar{X}

(C \land T \leq T^{'})

, where the values that

\bar{X}

may assume are restricted by the requirement that

C

be satisfied. This requirement vanishes in the case of DM type schemes, where

C

is true. Our notions of constrained type scheme and of instantiation constraint are standard: they are exactly those of

HM (X)

(Odersky, Sulzmann, and Wehr, 1999a).

The constraint true, which is always satisfied, mainly serves to indicate the absence of a nontrivial constraint, while false, which has no solution, may be understood as the indication of a type error. Composite constraints include conjunction and existential quantification, which have their standard meaning, as well as type scheme introduction and type scheme instantiation constraints, which are similar to Gustavsson and Svenningsson's constraint abstractions (2001b). In short, the construct def

x : σ

C

binds the name

x

to the type scheme

σ

within the constraint

C

. If

C

contains a subconstraint of
the form

x ⪯ T

, where this occurrence of

x

is free in

C

, then this subconstraint acquires the meaning

σ ⪯ T

. Thus, the constraint

x ⪯ T

is indeed an instantiation constraint, where the type scheme that is being instantiated is referred to by name. The constraint def

x : σ

C

may be viewed as an explicit substitution of the type scheme

σ

for the name x within

C

. Later (Section 1.5), we use such explicit substitutions to supplant typing environments. That is, where Damas and Milner's type system augments the current typing environment (DM-ABS, DM-LET), we introduce a new def binding in the current constraint; where it looks up the current typing environment (DM-VAR), we employ an instantiation constraint. The point is that it is then up to a constraint solver to choose a strategy for reducing explicit substitutions-for instance, one might wish to simplify

σ

before substituting it for

x

within

C

-whereas the use of environments in standard type systems such as DM and

H M (X)

imposes an eager substitution strategy, which is inefficient and thus never literally implemented. The use of type scheme introduction and instantiation constraints allows separating constraint generation and constraint solving without compromising efficiency, or, in other words, without introducing a gap between the description of the type inference algorithm and its actual implementation. Although the algorithm that we plan to describe is not new, its description in terms of constraints is: to the best of our knowledge, the only close relative of our def constraints is to be found in (Gustavsson and Svenningsson, 2001b). Fähndrich, Rehof, and Das's instantiation constraints (2000) are also related, but may be recursive and are meant to be solved using a semi-unification procedure, as opposed to a unification algorithm extended with facilities for creating and instantiating type schemes, as in our case.

One consequence of introducing constraints inside type schemes is that some type schemes have no instances at all, or have instances only if a certain constraint holds. For instance, the type scheme

σ = \forall x [

bool

=

int].X, where the nullary type constructors int and bool have distinct interpretations, has no instances; that is, no constraint of the form

σ ⪯ T^{'}

has a solution. The type scheme

σ = \forall Z [X = Y \to Z] . Z

has an instance only if

X = Y \to Z

holds for some Z; in other words, for every

T^{'}, σ ⪯ T^{'}

entails

\exists Z

(X = Y \to Z)

. (We define entailment on page 29.) We later prove that the constraint

\exists σ

is equivalent to

\exists Z . σ ⪯ Z

, where

Z \notin f t v (σ)

(Exercise 1.3.23). That is,

\exists σ

expresses the requirement that

σ

have an instance. Type schemes that do not have an instance indicate a type error, so in many situations, one wishes to avoid them; for this reason, we often use the constraint form let

x : σ

C

, which requires

σ

to have an instance and at the same time associates it with the name

x

. Because the def form is more primitive, it is easier to work with at a low level, but it is no longer explicitly used after Section 1.3; we always use let instead.

1.3.4 Definition: Environments

Γ

remain as in Definition 1.2.19, except DM type schemes S are replaced with constrained type schemes

σ

. We write

d f p i (Γ)

for

d p i (Γ) \cup f p i (Γ)

. We define def

\emptyset

C = C

and

def Γ; x : σ

C =

def

Γ

in def

x : σ

C

. Similarly, we define let

\emptyset

C = C

and let

Γ; x

σ

C =

let

Γ

in let

x : σ

C

. We define

\exists \emptyset =

true and

\exists (Γ; x : σ) =

\exists Γ \land def Γ

\exists σ

In order to establish or express certain laws of equivalence between constraints, we need constraint contexts. A context is a constraint with zero, one, or several holes, written []. The syntax of contexts is as follows:

C ::= ◻ | C | C \land C | \exists \bar{x} . C | def x : σ in C ∣ def x : \forall \bar{x} [C] . T in C

The application of a constraint context

C

to a constraint

C

, written

C [C]

, is defined in the usual way. Because a context may have any number of holes,

C

may disappear or be duplicated in the process. Because a hole may appear in the scope of a binder, some of

C

's free type variables and free program identifiers may become bound in

C [C]

. We write

dtv (C)

and

dpi (C)

for the sets of type variables and program identifiers, respectively, that

C

may thus capture. We write let

x : \forall \bar{x} [C] . T

C

for

\exists \bar{x} . C \land def x : \forall \bar{x} [C] . T

C

. Being able to state such a definition is why we require multi-hole contexts. We let range over existential constraint contexts, defined by

X ::= [] ∣ \exists \bar{X} . X

Meaning

We have defined the syntax of constraints and given an informal description of their meaning. We now give a formal definition of the interpretation of constraints. We begin with the definition of a model:

1.3.5 Definition: For every kind

κ

, let

M_{κ}

be a nonempty set, whose elements are the ground types of kind

κ

. In the following,

t

ranges over

M_{κ}

, for some

κ

that may be determined from the context. For every type constructor

F

of signature

K \Rightarrow κ

, let

F

denote a total function from

M_{K}

into

M_{κ}

, where the indexed product

M_{K}

is the set of all mappings of domain

dom (K)

that map every

d \in dom (K)

to an element of

M_{K (d)}

. For every predicate

P

of signature

κ_{1} \otimes \dots \otimes κ_{n} \Rightarrow \cdot

, let

P

denote a predicate on

M_{κ_{1}} \times \dots \times M_{κ_{n}}

. We require the predicate

\leq

M_{⋆} \times M_{⋆}

to be a partial order.

For the sake of convenience, we abuse notation and write

F

for both the type constructor and its interpretation; similarly for predicates. We freely assume that a binary equality predicate, whose interpretation is equality on

M_{κ}

, is available at every kind

κ

, so

T_{1} = T_{2}

, where

T_{1}

and

T_{2}

have kind

κ

, is a well-formed constraint.

By varying the set of type constructors, the set of predicates, the set of ground types, and the interpretation of type constructors and predicates, one may define an entire family of related type systems. We informally refer to the collection of these choices as

X

. Thus, the type systems

HM (X)

and

PCB (X)

, described in Sections 1.4 and 1.5, are parameterized by

X

The following examples give standard ways of defining the set of ground types and the interpretation of type constructors.

1.3.6 Example [Syntactic models]: For every kind

κ

, let

M_{κ}

consist of the closed types of kind

κ

. Then, ground types are types that do not have any free type variables, and form the so-called Herbrand universe. Let every type constructor

F

be interpreted as itself. Models that define ground types and interpret type constructors in this manner are referred to as syntactic.

1.3.7 EXAmple [TREe models]: Let a path

π

be a finite sequence of directions. The empty path is written

ϵ

and the concatenation of the paths

π

and

π^{'}

is written

π \cdot π^{'}

. Let a tree be a partial function

t

from paths to type constructors whose domain is nonempty and prefix-closed and such that, for every path

π

in the domain of

t

, if the type constructor

t (π)

has signature

K \Rightarrow κ

, then

π \cdot d \in dom (t)

is equivalent to

d \in dom (K)

and, furthermore, for every

d \in dom (K)

, the type constructor

t (π \cdot d)

has image kind

K (d)

. If

π

is in the domain of

t

, then the subtree of

t

rooted at

π

, written

t / π

, is the partial function

π^{'} \mapsto t (π \cdot π^{'})

. A tree is finite if and only if it has finite domain. A tree is regular if and only if it has a finite number of distinct subtrees. Every finite tree is thus regular. Let

M_{κ}

consist of the finite (resp. regular) trees

t

such that

t (ϵ)

has image kind

κ

: then, we have a finite (resp. regular) tree model.

F

has signature

K \Rightarrow κ

, one may interpret

F

as the function that maps

T \in M_{K}

to the ground type

t \in M_{κ}

defined by

t (ϵ) = F

and

t / d = T (d)

for

d \in dom (T)

, that is, the unique ground type whose head symbol is

F

and whose subtree rooted at

d

T (d)

. Then, we have a free tree model. Please note that free finite tree models coincide with syntactic models, as defined in the previous example.

Rows (Section 1.11) are interpreted in a tree model, albeit not a free one. The following examples suggest different ways of interpreting the subtyping predicate.

1.3.8 EXample [Equality models]: The simplest way of interpreting the subtyping predicate is to let

\leq

denote equality on every

M_{κ}

. Models that do so are referred to as equality models. When no predicate other than equality is available, we say that the model is equality-only.

1.3.9 Example [StRuctURal, NonstructURal SUbtyping]: Let a variance

ν

be a nonempty subset of

{-, +}

, written - (contravariant), + (covariant), or

\pm

(invariant) for short. Define the composition of two variances as an associative commutative operation with + as neutral element and such that

- - = +

and

\pm - = \pm \pm = \pm

. Now, consider a free (finite or regular) tree model, where every direction

d

comes with a fixed variance

ν (d)

. Define the variance

ν (π)

of a path

π

as the composition of the variances of its elements. Let

⩽

be a partial order on type constructors such that (i) if

F_{1} ⩽ F_{2}

holds and

F_{1}

and

F_{2}

have signature

K_{1} \Rightarrow κ_{1}

and

K_{2} \Rightarrow κ_{2}

, respectively, then

K_{1}

and

K_{2}

agree on the intersection of their domains and

κ_{1}

and

κ_{2}

coincide; and (ii)

F_{0} ⩽ F_{1} ⩽ F_{2}

implies

dom (F_{0}) \cap dom (F_{2}) \subseteq dom (F_{1})

. Let

⩽^{+}, ⩽^{-}

, and

⩽^{\pm}

stand for

⩽, ⩾

, and

=

, respectively. Then, define the interpretation of subtyping as follows: if

t_{1}, t_{2} \in M_{κ}

, let

t_{1} \leq t_{2}

hold if and only if, for every path

π \in dom (t_{1}) \cap dom (t_{2}), t_{1} (π) ⩽^{ν (π)} t_{2} (π)

holds. It is not difficult to check that

\leq

is a partial order on every

M_{κ}

. The reader is referred to (Kozen, Palsberg, and Schwartzbach., 1995) for more details about this construction. Models that define subtyping in this manner are referred to as nonstructural subtyping models.

A simple nonstructural subtyping model is obtained by letting the directions domain and codomain be contra- and covariant, respectively, and introducing, in addition to the type constructor

\to

, two type constructors

⊥

and

T

of signature

⋆

. This gives rise to a model where

⊥

is the least ground type,

T

is the greatest ground type, and the arrow type constructor is, as usual, contravariant in its domain and covariant in its codomain.

A typical use of nonstructural subtyping is in type systems for records. One may, for instance, introduce a covariant direction content of kind

⋆

, a kind

⋄

, a type constructor abs of signature

⋄

, a type constructor pre of signature

{

content

\mapsto ⋆} \Rightarrow ⋄

, and let pre

⩽

abs. This gives rise to a model where pre

t \leq

abs holds for every

t \in M_{⋆}

. This form of subtyping is called nonstructural because comparable ground types may have different shapes, such as

⊥

and

⊥\to ⊤

, or pre

T

and abs. Nonstructural subtyping has been studied, for example, in (Kozen, Palsberg, and Schwartzbach., 1995; Palsberg, Wand, and O'Keefe, 1997; Pottier, 2001b; Niehren and Priesnitz, 2003). Section 1.11 says more about typechecking operations on records.

An important particular case arises when any two type constructors related by

⩽

have the same arity. In that case, it is not difficult to show that any two ground types related by subtyping must have the same shape, that is, if

t_{1} \leq t_{2}

holds, then

dom (t_{1})

and

dom (t_{2})

coincide. For this reason, such an interpretation of subtyping is usually referred to as atomic or structural subtyping. It has been studied in the finite (Mitchell, 1984, 1991b; Frey, 1997; Rehof, 1997; Kuncak and Rinard, 2003; Simonet, 2003) and regular (Tiuryn and Wand,

cases. Structural subtyping is often used in automated program analyses that enrich standard types with atomic annotations without altering their shape.

Our last example suggests a predicate other than equality and subtyping.

1.3.10 Example [Conditional Constraints]: Consider a nonstructural subtyping model. For every type constructor

F

of image kind

κ

and for every kind

κ^{'}

, let

(F ⩽ \cdot \Rightarrow \cdot \leq \cdot)

be a predicate of signature

κ \otimes κ^{'} \otimes κ^{'} \Rightarrow \cdot

. Thus, if

T_{0}

has kind

κ

and

T_{1}, T_{2}

have the same kind, then

F ⩽ T_{0} \Rightarrow T_{1} \leq T_{2}

is a wellformed constraint, called a conditional subtyping constraint. Its interpretation is defined as follows: if

t_{0} \in M_{κ}

and

t_{1}, t_{2} \in M_{κ^{'}}

, then

F ⩽ t_{0} \Rightarrow t_{1} \leq t_{2}

holds if and only if

F ⩽ t_{0} (ϵ)

implies

t_{1} \leq t_{2}

. In other words, if

t_{0}

's head symbol exceeds

F

according to the ordering on type constructors, then the subtyping constraint

t_{1} \leq t_{2}

must hold; otherwise, the conditional constraint holds vacuously. Conditional constraints have been studied e.g. in (Reynolds, 1969a; Heintze, 1993; Aiken, Wimmers, and Lakshman, 1994; Pottier, 2000; Su and Aiken, 2001).

Many other kinds of constraints exist; see e.g. (Comon, 1993).

Throughout this chapter, we assume (unless stated otherwise) that the set of type constructors, the set of predicates, and the model-which, together, form the parameter

X

-are arbitrary and fixed.

As usual, the meaning of a constraint is a function of the meaning of its free type variables, which is given by a ground assignment. The meaning of free program identifiers may be defined as part of the constraint, if desired, using a def prefix, so it need not be given by a separate assignment.

1.3.11 Definition: A ground assignment

ϕ

is a total, kind-preserving mapping from

V

into

M

. Ground assignments are extended to types by

ϕ (F T_{1} \dots T_{n}) =

F (ϕ (T_{1}), \dots, ϕ (T_{n}))

. Then, for every type

T

of kind

κ, ϕ (T)

is a ground type of kind

κ

. Whether a constraint

C

holds under a ground assignment

ϕ

, written

ϕ ⊢ C

(read:

ϕ

satisfies

C

), is defined by the rules in Figure 1-5. A constraint

C

is satisfiable if and only if

ϕ ⊢ C

holds for some

ϕ

. It is false if and only if

ϕ ⊢ def Γ

C

holds for no ground assignment

ϕ

and environment

Γ

Let us now explain the rules that define constraint satisfaction (Figure 15). They are syntax-directed: that is, to a given constraint, at most one rule applies. It is determined by the nature of the first construct that appears under a maximal def prefix. CM-TRUE states that a constraint of the form def

Γ

in true is a tautology, that is, holds under every ground assignment. No rule matches constraints of the form def

Γ

in false, which means that such constraints do not have a solution. CM-PREDICATE states that the meaning

Figure 1-5: Meaning of constraints

of a predicate application is given by the predicate's interpretation within the model. More specifically, if

P

's signature is

κ_{1} \otimes \dots \otimes κ_{n} \Rightarrow \cdot

, then, by wellformedness of the constraint, every

T_{i}

is of kind

κ_{i}

, so

ϕ (T_{i})

is a ground type in

M_{κ_{i}}

. By Definition 1.3.5,

P

denotes a predicate on

M_{κ_{1}} \times \dots \times M_{κ_{n}}

, so the rule's premise is mathematically well-formed. It is independent of

Γ

, which is natural, since a predicate application has no free program identifiers. CMAND requires each of the conjuncts to be valid in isolation. The information in

Γ

is made available to each branch. CM-ExisTs allows the type variables

\vec{X}

to denote arbitrary ground types

\vec{t}

within

C

, independently of their image through

ϕ

. We implicitly require

\vec{X}

and

\vec{t}

to have matching kinds, so that

ϕ [\vec{X} \mapsto \vec{t}]

remains a kind-preserving ground assignment. The side condition

\bar{x} # f t v (Γ)

- which may always be satisfied by suitable

α

-conversion of the constraint

\exists \bar{X} . C

- prevents free occurrences of the type variables

\bar{X}

within

Γ

from being unduly affected. CM-INSTANCE concerns constraints of the form def

Γ

x ⪯ T^{'}

. The constraint

x ⪯ T^{'}

is turned into

σ ⪯ T^{'}

, where, according to the second premise,

σ

Γ (x)

. Please recall that constraints of such a form were introduced in Definition 1.3.3. The environment

Γ

is replaced with a suitable prefix of itself, namely

Γ_{1}

, so that the free program identifiers of

σ

retain their meaning.

It is intuitively clear that the constraints def

x : σ

C

and

[x \mapsto σ] C

have the same meaning, where the latter denotes the capture-avoiding substitution of

σ

for x throughout

C

. As a matter of fact, it would have been possible to use this equivalence as a definition of the meaning of def constraints, but the present style is pleasant as well. This confirms our (informal) claim that the def form is an explicit substitution form.

It is possible for a constraint to be neither satisfiable nor false. Consider, for instance, the constraint

\exists Z \cdot x ⪯ z

. Because the identifier

x

is free, CMINSTANCE is not applicable, so the constraint is not satisfiable. Furthermore,
placing it within the context let

x : \forall X . X

◻

makes it satisfied by every ground assignment, so it is not false. Here, the assertions "

C

is satisfiable" and "

C

is false" are opposite when

f p i (C) = \emptyset

holds, whereas in a standard first-order logic, they always are.

In a judgement of the form

ϕ ⊢ C

, the ground assignment

ϕ

applies to the free type variables of

C

. This is made precise by the following statements. In the second one,

\circ

is composition and

θ (C)

is the capture-avoiding application of the type substitution

θ

C

1.3.12 Lemma: If

\bar{x} # ftv (C)

holds, then

ϕ ⊢ C

and

ϕ [\vec{x} \mapsto \vec{t}] ⊢ C

are equivalent.

1.3.13 Lemma:

ϕ \circ θ ⊢ C

and

ϕ ⊢ θ (C)

are equivalent.

Reasoning with constraints

Because constraints lie at the heart of our treatment of ML-the-type-system, most of our proofs involve establishing logical properties of constraints, that is, entailment or equivalence assertions. Let us first define these notions.

1.3.14 Definition: We write

C_{1} ⊩ C_{2}

, and say that

C_{1}

entails

C_{2}

, if and only if, for every ground assignment

ϕ

and for every environment

Γ, ϕ ⊢ def Γ

C_{1}

implies

ϕ ⊢ def Γ

C_{2}

. We write

C_{1} \equiv C_{2}

, and say that

C_{1}

and

C_{2}

are equivalent, if and only if

C_{1} ⊩ C_{2}

and

C_{2} ⊩ C_{1}

hold.

This definition measures the strength of a constraint by the set of pairs

(ϕ, Γ)

that satisfy it, and considers a constraint stronger if fewer such pairs satisfy it. In other words,

C_{1}

entails

C_{2}

when

C_{1}

imposes stricter requirements on its free type variables and program identifiers than

C_{2}

does. We remark that

C

is false if and only if

C \equiv

false holds. It is straightforward to check that entailment is reflexive and transitive and that

\equiv

is indeed an equivalence relation.

We immediately exploit the notion of constraint equivalence to define what it means for a type constructor to be covariant, contravariant, or invariant with respect to one of its parameters. Let

F

be a type constructor of signature

κ_{1} \otimes

\dots \otimes κ_{n} \Rightarrow κ

. Let

i \in {1, \dots, n} . F

is covariant (resp. contravariant, invariant) with respect to its

i^{th}

parameter if and only if, for all types

T_{1}, \dots, T_{n}

and

T_{i}^{'}

of appropriate kinds, the constraint

F T_{1} \dots T_{i} \dots T_{n} \leq F T_{1} \dots T_{i}^{'} \dots T_{n}

is equivalent to

T_{i} \leq T_{i}^{'}

(resp.

T_{i}^{'} \leq T_{i}, T_{i} = T_{i}^{'}

). We let the reader check the following facts: (i) in an equality model, these three notions coincide; (ii) in an equality free tree model, every type constructor is invariant with respect to each of its parameters; and (iii) in a nonstructural subtyping model, if the direction

d

has been declared covariant (resp. contravariant, invariant), then every type constructor whose arity includes

d

is covariant (resp. contravariant,
invariant) with respect to

d

. In the following, we require the type constructor

\to

to be contravariant with respect to its domain and covariant with respect to its codomain - a standard requirement in type systems with subtyping (TAPL Chapter 15). These properties are summed up by the following equivalence law:

\begin{matrix} (C-ARrow) & T_{1} \to T_{2} \leq T_{1}^{'} \to T_{2}^{'} \equiv T_{1}^{'} \leq T_{1} \land T_{2} \leq T_{2}^{'} \end{matrix}

Please note that this is a high-level requirement about the interpretation of types and of the subtyping predicate. In an equality free tree model, for instance, it is always satisfied. In a nonstructural subtyping model, it boils down to requiring that the directions domain and codomain be declared contravariant and covariant, respectively. In the general case, we do not have any knowledge of the model, and cannot formulate a more precise requirement. Thus, it is up to the designer of the model to ensure that C-ARrow holds.

We also exploit the notion of constraint equivalence to define what it means for two type constructors to be incompatible. Two type constructors

F_{1}

and

F_{2}

with the same image kind are incompatible if and only if all constraints of the form

F_{1} {\vec{T}}_{1} \leq F_{2} {\vec{T}}_{2}

and

F_{2} {\vec{T}}_{2} \leq F_{1} {\vec{T}}_{1}

are false; then, we write

F_{1} ⋈ F_{2}

. Please note that in an equality free tree model, any two distinct type constructors are incompatible. In the following, we often indicate that a newly introduced type constructor must be isolated. We implicitly require that, whenever each of

F_{1}

and

F_{2}

is isolated,

F_{1}

and

F_{2}

be incompatible. Thus, the notion of "isolation" provides a concise and modular way of stating a collection of incompatibility requirements. We consider the type constructor

\to

isolated.

Entailment is preserved by arbitrary constraint contexts, as stated by the following theorem. As a result, constraint equivalence is a congruence. Throughout this chapter, these facts are often used implicitly.

1.3.15 Theorem [Congruence]:

C_{1} ⊩ C_{2}

implies

C [C_{1}] ⊩ C [C_{2}]

We now give a series of lemmas that provide useful entailment laws.

The following is a standard property of existential quantification.

1.3.16 Lemma:

C ⊩ \exists \bar{x}

C

The following lemma states that any supertype of an instance of

σ

is also an instance of

σ

1.3.17 Lemma:

σ ⪯ T \land T \leq T^{'} ⊩ σ ⪯ T^{'}

The next lemma gives another interesting simplification law.

1.3.18 Lemma:

X \notin f t v (T)

implies

\exists X . (X = T) \equiv

true.

The following lemma states that, provided

D

is satisfied, the type

T

is an instance of the constrained type scheme

\forall \bar{x} [D]

.T.

1.3.19 Lemma:

D ⊩ \forall \bar{X} [D] . T ⪯ T

This technical lemma helps justify Definition 1.3.21 below.

1.3.20 Lemma: Let

Z \notin ftv (C, σ, T)

. Then,

C ⊩ σ ⪯ T

holds if and only if

C \land T \leq

Z ⊩ σ ⪯ Z

holds.

It is useful to define what it means for a type scheme

σ_{1}

to be more general than a type scheme

σ_{2}

. Our informal intent is for

σ_{1} ⪯ σ_{2}

to mean: every instance of

σ_{2}

is an instance of

σ_{1}

. In Definition 1.3.3, we have introduced the constraint form

σ ⪯ T

as syntactic sugar. Similarly, one might wish to make

σ_{1} ⪯ σ_{2}

a derived constraint form; however, this is impossible, because neither universal quantification nor implication are available in the constraint language. We can, however, exploit the fact that these logical connectives are implicit in entailment assertions by defining a judgement of the form

C ⊩ σ_{1} ⪯ σ_{2}

, whose meaning is: under the constraint

C

σ_{1}

is more general than

σ_{2}

1.3.21 Definition: We write

C ⊩ σ_{1} ⪯ σ_{2}

if and only if

Z \notin ftv (C, σ_{1}, σ_{2})

implies

C \land σ_{2} ⪯ Z ⊩ σ_{1} ⪯ z

. We write

C ⊩ σ_{1} \equiv σ_{2}

when both

C ⊩ σ_{1} ⪯ σ_{2}

and

C ⊩ σ_{2} ⪯ σ_{1}

hold.

This notation is not ambiguous because the assertion

C ⊩ σ ⪯ T

, whose meaning was initially given by Definitions 1.3 .3 and 1.3.14, retains the same meaning under the new definition - this is shown by Lemma 1.3.20 above.

The next lemma provides a way of exploiting the ordering between type schemes introduced by Definition 1.3.21. It states that a type scheme occurs in contravariant position when it is within a def prefix. In other words, the more general the type scheme, the weaker the entire constraint.

1.3.22 Lemma:

C ⊩ σ_{1} ⪯ σ_{2}

implies

C \land def x : σ_{2}

D ⊩ def x : σ_{1}

D

The following exercise generalizes this result to let forms.

1.3.23 EXERcISE

[⋆ ⋆, ↛]

: Prove that

Z \notin f t v (σ)

implies

\exists σ \equiv \exists Z . σ ⪯ Z

. Explain why, as a result,

C ⊩ σ_{1} ⪯ σ_{2}

implies

C \land \exists σ_{2} ⊩ \exists σ_{1}

. Use this fact to prove that

C ⊩ σ_{1} ⪯ σ_{2}

implies

C \land

let x :

σ_{2}

D ⊩

let

x : σ_{1}

D

The next lemma states that, modulo equivalence, the only constraint that constrains

x

without explicitly referring to it is false.

1.3.24 Lemma:

C ⊩ x ⪯ T

and

x \notin f p i (C)

imply

C \equiv

false.

The following lemma states that the more universal quantifiers are present, the more general the type scheme.

1.3.25 Lemma: let

x : \forall \bar{x} [C_{1}] . T

C_{2} ⊩

let

x : \forall \bar{x} \bar{Y} [C_{1}] . T

C_{2}

Conversely, and perhaps surprisingly, it is sometimes possible to remove some type variables from the universal quantifier prefix of a type scheme without compromising its generality. This is the case when the value of these type variables is determined in a unique way. In short,

C

determines

\bar{Y}

if and only if, given the values of

f t v (C) ∖ \bar{Y}

and given that

C

holds, it is possible to reconstruct, in a unique way, the values of

\bar{Y}

1.3.26 Definition:

C

determines

\bar{Y}

if and only if, for every environment

Γ

, two ground assignments that satisfy def

Γ

C

and that coincide outside

\bar{Y}

must coincide on

\bar{Y}

as well.

Two concrete instances of determinacy, one of which is valid only in free tree models, are given by Lemma 1.8.7 on page 82. Determinacy is exploited by the equivalence law C-LETALL in Figure 1-6.

We now give a toolbox of constraint equivalence laws. It is worth noting that they do not form a complete axiomatization of constraint equivalencein fact, they cannot, since the syntax and meaning of constraints is partly unspecified.

1.3.27 Theorem: All equivalence laws in Figure 1-6 hold.

Let us explain. C-AND and C-ANDAnd state that conjunction is commutative and associative. C-DuP states that redundant conjuncts may be freely added or removed, where a conjunct is redundant if and only if it is entailed by another conjunct. Throughout this chapter, these three laws are often used implicitly. C-ExEx and C-Ex* allow grouping consecutive existential quantifiers and suppressing redundant ones, where a quantifier is redundant if and only if it does not occur free within its scope. C-ExAnd allows conjunction and existential quantification to commute, provided no capture occurs; it is known as a scope extrusion law. When the rule is oriented from left to right, its side-condition may always be satisfied by suitable

α

-conversion. C-ExTrans states that it is equivalent for a type

T^{'}

to be an instance of

σ

or to be a supertype of some instance of

σ

. We remark that the instances of a monotype are its supertypes, that is, by Definition 1.3.3,

T ⪯ T^{'}

and

T \leq T^{'}

are equivalent. As a result, specializing C-ExTRans to the case where

σ

is a monotype, we find that

T \leq T^{'}

is equivalent to

\exists Z

(T \leq Z \land Z \leq T^{'}

), for fresh

Z

, a standard equivalence law. When oriented from left to right, it becomes an interesting simplification law: in a chain of subtyping constraints, an intermediate variable such as Z may be suppressed, provided it is local, as witnessed by the existential quantifier

\exists Z

. C-INID states that, within the scope of the binding

x : σ

, every free occurrence of

x

may be safely replaced with

σ

. The restriction to free occurrences stems from the side-condition

x \notin d p i (C)

. When the

\begin{aligned} C_{1} \land C_{2} \equiv C_{2} \land C_{1} \\ (C_{1} \land C_{2}) \land C_{3} \equiv C_{1} \land (C_{2} \land C_{3}) \\ C_{1} \land C_{2} \equiv C_{1} if C_{1} ⊩ C_{2} \\ \exists \bar{X} \cdot \exists \bar{Y} \cdot C \equiv \exists \bar{X} \bar{Y} \cdot C \\ \exists \bar{x} . C \equiv C \\ (\exists \bar{X} \cdot C_{1}) \land C_{2} \equiv \exists \bar{X} \cdot (C_{1} \land C_{2}) \\ (C-DuP) \\ (C - E x E x) \\ (C - {E x}^{*}) \\ \exists Z . (σ ⪯ Z \land Z \leq T^{'}) \equiv σ ⪯ T^{'} \\ if \bar{x} # f t v (C) \\ if \bar{x} # f t v (C_{2}) \\ (C-ExAnd) \\ let x : σ in C [x ⪯ T^{'}] \equiv let x : σ in C [σ ⪯ T^{'}] \\ if x \notin d p i (C) and dtv (C) # f tv (σ) and {x} \cup d p i (C) # f p i (σ) \\ let Γ in C \equiv \exists Γ \land C if d p i (Γ) # f p i (C) \\ (C-ExTrans) \\ if z \notin f t v (σ, T^{'}) \\ let Γ; x : \forall \bar{x} [C_{1}] . T in C_{2} \equiv let Γ; x : \forall \bar{x} [let Γ in C_{1}] . T in C_{2} \\ if \bar{X} # f t v (Γ) and d p i (Γ) # f p i (Γ) \\ if \bar{Y} # ftv (T) \\ true \equiv \exists \bar{X} \cdot (\vec{X} = \vec{T}) \end{aligned}

Figure 1-6: Constraint equivalence laws
rule is oriented from left to right, its other side-conditions, which require the context let

x : σ

C

not to capture

σ

's free type variables or free program identifiers, may always be satisfied by suitable

α

-conversion. C-IN* complements the previous rule by allowing redundant let bindings to be simplified. We remark that C-INID and C-IN* provide a simple procedure for eliminating let forms. C-INAND states that the let form commutes with conjunction; CINAND* spells out a common particular case. C-INEX states that it commutes with existential quantification. When the rule is oriented from left to right, its side-condition may always be satisfied by suitable

α

-conversion. C-LETLET states that let forms may commute, provided they bind distinct program identifiers and provided no free program identifiers are captured in the process. C-LETAnd allows the conjunct

C_{1}

to be moved outside of the constrained type scheme

\forall \bar{x} [C_{1} \land C_{2}]

.T, provided it does not involve any of the universally quantified type variables

\bar{X}

. When oriented from left to right, the rule yields an important simplification law: indeed, taking an instance of

\forall \bar{X} [C_{2}]

. T is less expensive than taking an instance of

\forall \bar{x} [C_{1} \land C_{2}]

. T, since the latter involves creating a copy of

C_{1}

, while the former does not. C-LETDUP allows pushing a series of let bindings into a constrained type scheme, provided no capture occurs in the process. It is not used as a simplification law but as a tool in some proofs. C-LETEx states that it does not make any difference for a set of type variables

\bar{Y}

to be existentially quantified inside a constrained type scheme or part of the type scheme's universal quantifiers. Indeed, in either case, taking an instance of the type scheme means producing a constraint where

\bar{Y}

is existentially quantified. C-LETALL provides a restricted converse of Lemma 1.3.25. Together, C-LETEx and C-LETALL allow-in some situations only - to hoist existential quantifiers out of the left-hand side of a let form.

1.3.28 Example: C-LetAll would be invalid without the condition that

\exists \bar{X} . C_{1}

determines

\bar{Y}

. Consider, for instance, the constraint let

x : \forall Y . Y \to Y

(x ⪯

int

\to

int

\land x ⪯

bool

\to

bool) (1), where int and bool are incompatible nullary type constructors. By C-INID and C-IN*, it is equivalent to

\exists Y

Y \to

Y \leq

int

\to

int

) \land \exists Y

Y \to Y \leq

bool

\to

bool

)

, that is, true. Now, if C-LETALL was valid without its side-condition, then (1) would also be equivalent to

\exists Y

.let

x : Y \to Y

(x ⪯

int

\to

int

\land x ⪯

bool

\to

bool), which by C-INID and C-IN* is

\exists Y

.(Y

\to Y \leq

int

\to

int

\land Y \to Y \leq

bool

\to

bool). By C-ARROW and C-ExTrans, this is int

=

bool, that is, false. Thus, the law is invalid in this case. It is easy to see why: when the type scheme

σ

contains a

\forall Y

quantifier, every instance of

σ

receives its own

\exists Y

quantifier, making Y a distinct (local) type variable; when

Y

is not universally quantified, however, all instances of

σ

share references to a single (global) type variable Y. This corresponds to the
intuition that, in the former case,

σ

is polymorphic in Y, while in the latter case, it is monomorphic in Y. Lemma 1.3.25 states that, when deprived of its sidecondition, C-LETALL is only an entailment law, as opposed to an equivalence law. Similarly, it is in general invalid to hoist an existential quantifier out of the left-hand side of a let form. To see this, one may study the (equivalent) constraint let

x : \forall X [\exists Y . X = Y \to Y] . X

(x ⪯

int

\to

int

\land x ⪯

bool

\to

bool).

Naturally, in the above examples, the side-condition "true determines

Y

" does not hold: by Definition 1.3.26, it is equivalent to "two ground assignments that coincide outside Y must coincide on Y as well', which is false as soon as

M_{⋆}

contains two distinct elements, such as int and bool here. There are cases, however, where the side-condition does hold. For instance, we later prove that

\exists X . Y =

int determines

Y

; see Lemma 1.8.7. As a result, C-LETALL states that let

x : \forall X Y [Y =

int].

Y \to X

C

(1) is equivalent to

\exists Y

.let

x : \forall X [Y = int] . Y \to

X

C

(2), provided

Y \notin f t v (C)

. The intuition is simple: because

Y

is forced to assume the value int by the equation

Y =

int, it makes no difference whether

Y

is or isn't universally quantified. We remark that, by C-LETAND, (2) is equivalent to

\exists Y

Y = int \land

let

x : \forall X . Y \to X

C

) (3). In an efficient constraint solver, simplifying (1) into (3) before using C-INID to eliminate the let form is worthwhile, since doing so obviates the need for copying the type variable

Y

and the equation

Y =

int at every free occurrence of

x

inside

C

C-LETSuB is the analogue of an environment strengthening lemma: roughly speaking, it states that, if a constraint holds under the assumption that

x

has type

X

, where

X

is some supertype of

T

, then it also holds under the assumption that

x

has type

T

. The last three rules deal with the equality predicate.

C - E Q

states that it is valid to replace equals with equals; note the absence of a side-condition. When oriented from left to right, C-NAME allows introducing fresh names

\vec{X}

for the types

\vec{T}

. As always,

\vec{X}

stands for a vector of distinct type variables. Of course, this makes sense only if the definition is not circular, that is, if the type variables

\bar{X}

do not occur free within the terms

\bar{T}

. When oriented from right to left, C-NAME may be viewed as a simplification law: it allows eliminating type variables whose value has been determined. C-NAMEEQ is a combination of

C - E Q

and

C - N A M E

. It shows that applying an idempotent substitution to a constraint

C

amounts to placing

C

within a certain context. This immediately yields a proof of the following fact:

1.3.29 Lemma:

C ⊩ D

implies

θ (C) ⊩ θ (D)

It is important to stress that, because the effect of a type substitution may be emulated using equations, conjunction, and existential quantification, there is no need ever to employ type substitutions in the definition of a constraintbased type system - it is possible, instead, to express every concept in terms
of constraints. In this chapter, we follow this route, and use type substitutions only when dealing with the type system DM, whose historical formulation is substitution-based.

So far, we have considered def a primitive constraint form and defined the let form in terms of def, conjunction, and existential quantification. The motivation for this approach was to simplify the proof of several constraint equivalence laws. However, in the remainder of this chapter, we work with let forms exclusively and never employ the def construct. As a result, it is possible, from here on, to discard def and pretend that let is primitive. This change in perspective offers us a few extra properties, stated in the next two lemmas. First, every constraint that contains a false subconstraint must be false. Second, no satisfiable constraint has a free program identifier.

1.3.30 Lemma:

C [

false

] \equiv

false.

1.3.31 Lemma: If

C

is satisfiable, then

f p i (C) = \emptyset

Reasoning with constraints in an equality-only syntactic model

We have given a number of equivalence laws that are valid with respect to any interpretation of constraints, that is, within any model. However, an important special case is that of equality-only syntactic models. Indeed, in that specific setting, our constraint-based type systems are in close correspondence with DM. In short, we aim to prove that every satisfiable constraint admits a canonical solved form, to show that this notion corresponds to the standard concept of a most general unifier, and to establish a few technical properties of most general unifiers.

Thus, let us now assume that constraints are interpreted in an equality-only syntactic model. Let us further assume that, for every kind

κ

, (i) there are at least two type constructors of image kind

κ

and (ii) for every type constructor

F

of image kind

κ

, there exists

t \in M_{κ}

such that

t (ϵ) = F

. We refer to models that violate (i) or (ii) as degenerate; one may argue that such models are of little interest. The assumption that the model is nondegenerate is used in the proof of Lemmas 1.3.32 and 1.3.39.

Under these new assumptions, the interpretation of equality coincides with its syntax: every equation that holds in the model is in fact a syntactic truism. The converse, of course, holds in every model.

1.3.32 Lemma: If true

⊩ T = T^{'}

holds, then

T

and

T^{'}

coincide.

In a syntactic model, ground types are finite trees. As a result, cyclic equations, such as

X =

int

\to X

, are false.

1.3.33 Lemma:

X \in f t v (T)

and

T \notin V

imply

(X = T) \equiv

false.

A solved form is a conjunction of equations, where the left-hand sides are distinct type variables that do not appear in the right-hand sides, possibly surrounded by a number of existential quantifiers. Our definition is identical to Lassez, Maher and Marriott's solved forms (1988) and to Jouannaud and Kirchner's tree solved forms (1991), except we allow for prenex existential quantifiers, which are made necessary by our richer constraint language. Jouannaud and Kirchner also define

d a g

solved forms, which may be exponentially smaller. Because we define solved forms only for proof purposes, we need not take performance into account at this point. The efficient constraint solver presented in Section 1.8 does manipulate graphs, rather than trees. Type scheme introduction and instantiation constructs cannot appear within solved forms; indeed, provided the constraint at hand has no free program identifiers, they can be expanded away. For this reason, their presence in the constraint language has no impact on the results contained in this section.

1.3 .34 Definition: A solved form is of the form

\exists \bar{Y} . (\vec{X} = \vec{T})

, where

\bar{X} # f t v (\bar{T})

Solved forms offer a convenient way of reasoning about constraints because every satisfiable constraint is equivalent to one. In other words, every constraint is equivalent to either a solved form or false. This property is established by the following lemma, whose proof provides a simple but effective procedure to rewrite a constraint to either a solved form or false.

1.3.35 Lemma: Let

f p i (C) = \emptyset

. Then,

C

is equivalent to either a solved form or false.

Proof: We first establish that every conjunction of equations is equivalent to either a solved form or false. To do so, we present Robinson's unification algorithm (1971) as a rewriting system. The system's invariant is to operate on constraints of the form either

\vec{X} = \vec{T}; C

, where

\bar{X} # tv (\bar{T}, C)

and the semicolon is interpreted as a distinguished conjunction, or false. We identify equations in

C

up to commutativity. The system is defined as follows:

\begin{array}{rrll} \vec{X} = \vec{T}; & X = X \land C \to & \vec{x} = \vec{T}; C \\ \vec{x} = & \vec{T}; & F {\vec{T}}_{1} = F {\vec{T}}_{2} \land C \to & \to \vec{x} = \vec{T}; {\vec{T}}_{1} = {\vec{T}}_{2} \land C \\ \vec{X} = \vec{T}; & F_{1} {\vec{T}}_{1} = F_{2} {\vec{T}}_{2} \land C \to & \to & false \\ if F_{1} \neq F_{2} \\ \vec{X} = & \vec{T}; & X = T \land C \to & \to \vec{X} = [X \mapsto T] \vec{T} \land X = T; [X \mapsto T] C \\ if X \notin f t v (T) \\ \vec{x} = & \vec{T}; & X = T \land C \to & false \\ if X \in f t v (T) and T \notin V \end{array}

It is straightforward to check that the above invariant is indeed preserved by the rewriting system. Let us check that constraint equivalence is also preserved. For the first rule, this is immediate. For the second and third rules, it
follows from the fact that we have assumed a free tree model; for the fourth rule, a consequence of

C - E Q

; for the last rule, a consequence of Lemma 1.3.33. Furthermore, the system is terminating; this is witnessed by an ordering where false is the least element and where constraints of the form

\vec{X} = \vec{T}; C

are ordered lexicographically, first by the number of type variables that appear free within

C

, second by the size of

C

. Last, a normal form for this rewriting system must be of the form either

\vec{X} = \vec{T}

; true, where (by the invariant)

\bar{X} # f t v (\bar{T})

- that is, a solved form, or false.

Next, we show that the present lemma holds when

C

is built out of equations, conjunction, and existential quantification. Orienting C-ExAnd from left to right yields a terminating rewriting system that preserves constraint equivalence. The normal form of

C

must be

\exists \bar{Y}

C^{'}

, where

C^{'}

is a conjunction of equations. By the previous result,

C^{'}

is equivalent to either a solved form or false. Because solved forms are preserved by existential quantification and because

\exists \bar{Y}

.false is false, the same holds of

C

Last, we establish the result in the general case. We assume

f p i (C) = \emptyset

(1). Orienting C-INID and C-IN* from left to right yields a terminating rewriting system that preserves constraint equivalence. The normal form

C^{'}

C

cannot contain any type scheme introduction forms; given (1), it cannot contain any instantiation forms either. Thus,

C^{'}

is built out of equations, conjunction, and existential quantification only. By the previous result, it is equivalent to either a solved form or false, which implies that the same holds of

C

It is possible to impose further restrictions on solved forms. A solved form

\exists \bar{Y} . (\vec{X} = \vec{T})

is canonical if and only if its free type variables are exactly

\bar{X}

. This is stated, in an equivalent way, by the following definition.

1.3.36 Definition: A canonical solved form is a constraint of the form

\exists \bar{Y}

(\vec{X} = \vec{T})

, where

f t v (\bar{T}) \subseteq \bar{Y}

and

\bar{X} # \bar{Y}

1.3.37 Lemma: Every solved form is equivalent to a canonical solved form.

It is easy to describe the solutions of a canonical solved form: they are the ground refinements of the substitution

[\vec{X} \mapsto \vec{T}]

1.3.38 Lemma: A ground assignment

ϕ

satisfies a canonical solved form

\exists \bar{Y}

(\vec{X} = \vec{T})

if and only if there exists a ground assignment

ϕ^{'}

such that

ϕ (\vec{X}) = ϕ^{'} (\vec{T})

. As a result, every canonical solved form is satisfiable.

Proof: Let

\exists \bar{Y}

(\vec{X} = \vec{T})

be a canonical solved form. By CM-ExisTs and CMPredicate,

ϕ

satisfies

\exists \bar{Y}

(\vec{X} = \vec{T})

if and only if there exists

\vec{t}

such that

ϕ [\vec{Y} \mapsto

\vec{t}] (\vec{X}) = ϕ [\vec{Y} \mapsto \vec{t}] (\vec{T})

. Thanks to the hypotheses

\bar{X} # \bar{Y}

and

f t v (\bar{T}) \subseteq \bar{Y}

, this is equivalent to the existence of a ground assignment

ϕ^{'}

such that

ϕ (\vec{\vec{X}}) = ϕ^{'} (\vec{T})

Thus, for every ground assignment

ϕ^{'}, ϕ^{'} [\vec{X} \mapsto ϕ^{'} (\vec{T})]

satisfies

\exists \bar{Y}

(\vec{X} = \vec{T})

, which proves that this constraint is satisfiable.

Together, Lemmas 1.3.37 and 1.3.38 imply that every solved form is satisfiable. Our interest in canonical solved forms stems from the following fundamental property, which provides a syntactic characterization of entailment between canonical solved forms: if

\exists {\bar{Y}}_{1} \cdot (\vec{X} = {\vec{T}}_{1})

is more specific than

\exists {\bar{Y}}_{2} \cdot (\vec{X} = {\vec{T}}_{2})

, in a logical sense, then

{\vec{T}}_{1}

refines

{\vec{T}}_{2}

, in a syntactic sense. The converse also holds (can you prove it?), but is not needed here.

1.3.39 LEMma: If

\exists {\bar{Y}}_{1} \cdot (\vec{X} = {\vec{T}}_{1}) ⊩ \exists {\bar{Y}}_{2} \cdot (\vec{X} = {\vec{T}}_{2})

, where both sides are canonical solved forms, then there exists a type substitution

φ

such that

{\vec{T}}_{1} = φ ({\vec{T}}_{2})

As a corollary, we find that canonical solved forms are unique up to

α

conversion and up to

C

-Ex*, provided the set

\bar{X}

of their free type variables is fixed.

1.3.40 LEMma: If the canonical solved forms

\exists {\bar{Y}}_{1} \cdot (\vec{X} = {\vec{T}}_{1})

and

\exists {\bar{Y}}_{2} \cdot (\vec{X} = {\vec{T}}_{2})

are equivalent, then there exists a renaming

ρ

such that

{\vec{T}}_{1} = ρ ({\vec{T}}_{2})

Please note that the fact that the canonical solved forms

\exists {\bar{Y}}_{1} \cdot ({\vec{X}}_{1} = {\vec{T}}_{1})

and

\exists {\bar{Y}}_{2} \cdot ({\vec{X}}_{2} = {\vec{T}}_{2})

are equivalent does not imply that

{\bar{X}}_{1}

and

{\bar{X}}_{2}

coincide. Consider, for example, the canonical solved forms true and

\exists Y . (X = Y)

, which by C-NAMEEQ are equivalent. One might wish to further restrict canonical solved forms by requiring

\bar{X}

to be the set of essential type variables of the constraint

\exists \bar{Y} . (\vec{X} = \vec{T})

, that is, the set of the type variables that appear free in all equivalent constraints. However, as far our technical development is concerned, it seems more convenient not to do so. Instead, we show that it is possible to explicitly restrict or extend

\bar{X}

when needed (Lemma 1.3.43).

The following definition allows entertaining a dual view of canonical solved forms, either as constraints or as idempotent type substitutions. The latter view is commonly found in standard treatments of unification (Lassez, Maher, and Marriott, 1988; Jouannaud and Kirchner, 1991) and in classic presentations of ML-the-type-system.

1.3.41 Definition: If

[\vec{X} \mapsto \vec{T}]

is an idempotent substitution of domain

\bar{X}

, let

\exists [\vec{X} \mapsto \vec{T}]

denote the canonical solved form

\exists \bar{Y} . (\vec{X} = \vec{T})

, where

\bar{Y} = ftv (\bar{T})

. An idempotent substitution

θ

is a most general unifier of the constraint

C

if and only if

\exists θ

and

C

are equivalent.

By definition, equivalent constraints admit the same most general unifiers. Many properties of canonical solved forms may be reformulated in terms of most general unifiers. By Lemmas 1.3.31, 1.3.35, and 1.3.37, every satisfiable constraint admits a most general unifier. By Lemma 1.3.40, if

[\vec{X} \mapsto {\vec{T}}_{1}]

and

[\vec{X} \mapsto {\vec{T}}_{2}]

are most general unifiers of

C

, then

{\vec{T}}_{1}

and

{\vec{T}}_{2}

coincide up to a renaming. Conversely, if

[\vec{X} \mapsto \vec{T}]

is a most general unifier of

C

and if

\bar{X} # ρ

holds, then

[\vec{X} \mapsto ρ \vec{T}]

is also a most general unifier of

C

; indeed, these two substitutions correspond to

α

-equivalent canonical solved forms.

The following result relates the substitution

θ

to the canonical solved form

\exists θ

, stating that every ground refinement of the former satisfies the latter.

1.3.42 Lemma:

θ (\exists θ) \equiv

true.

The following lemma offers two technical results: the domain of a most general unifier of

C

may be restricted so as to become a subset of

f t v (C)

; it may also be extended to include arbitrary fresh variables. The next lemma is a simple corollary.

1.3.43 Lemma: Let

θ

be a most general unifier of

C

. If

\bar{Z} # f tv (C)

, then

θ ∖ \bar{z}

is also a most general unifier of

C

. If

\bar{z} # θ

, then there exists a most general unifier of

C

that extends

θ

and whose domain is

dom (θ) \cup \bar{z}

1.3.44 Lemma: Let

θ_{1}

and

θ_{2}

be most general unifiers of

C

. Let

\bar{x} = dom (θ_{1}) \cap

dom (θ_{2})

. Then,

θ_{1} (\bar{X})

and

θ_{2} (\bar{X})

coincide up to a renaming.

Our last technical result relates the most general unifiers of

C

with the most general unifiers of

\exists

X.C. It states that the former are extensions of the latter. Furthermore, under a few freshness conditions, every most general unifier of

\exists

C

may be extended to yield a most general unifier of

C

1.3.45 Lemma: If

θ

is a most general unifier of

C

, then

θ ∖ X

is a most general unifier of

\exists x . C

. Conversely, if

θ

is a most general unifier of

\exists X . C

and

x # θ

and

f t v (\exists

X.C

C) dom (θ)

, then there exists a type substitution

θ^{'}

such that

θ^{'}

extends

θ, θ^{'}

is a most general unifier of

C

, and

dom (θ^{'}) = dom (θ) \cup X

$1.4 HM (X)$

Constraint-based type systems appeared during the 1980s (Mitchell, 1984; Fuh and Mishra, 1988) and were widely studied during the following decade (Curtis, 1990; Aiken and Wimmers, 1993; Jones, 1994a; Smith, 1994; Palsberg, 1995; Trifonov and Smith, 1996; Fähndrich, 1999; Pottier, 2001b). We now present one such system, baptized

HM (X)

because it is a parameterized extension of Hindley and Milner's type discipline; the meaning of the parameter

X

was explained on page 24. Its original description is due to Odersky, Sulzmann, and Wehr (1999a). Since then, it has been completed in a number of works (Sulzmann, Müller, and Zenger, 1999; Sulzmann, 2000; Pottier, 2001a;

Skalka and Pottier, 2002). Each of these presentations introduces minor variations. Here, we follow (Pottier, 2001a), which is itself inspired by (Sulzmann, Müller, and Zenger, 1999).

Definition

Our presentation of

HM (X)

relies on the constraint language introduced in section 1.3. Technically, our approach of constraints is more direct than that of (Odersky, Sulzmann, and Wehr, 1999a). We interpret constraints within a model, give conjunction and existential quantification their standard meaning, and derive a number of equivalence laws (Section 1.3). Odersky et al., on the other hand, do not explicitly rely on a logical interpretation; instead, they axiomatize constraint equivalence, that is, they consider a number of equivalence laws as axioms. Thus, they ensure that their high-level proofs, such as type soundness and correctness and completeness of type inference, are independent of the low-level details of the logical interpretation of constraints. Their approach is also more general, since it allows dealing with other logical interpretations - such as "open-world" interpretations, where constraints are interpreted not within a fixed model, but within a family of extensions of a "current" model. In this chapter, we have avoided this extra layer of abstraction, for the sake of definiteness; however, the changes required to adopt Odersky et al.'s approach would not be extensive, since the forthcoming proofs do indeed rely mostly on constraint equivalence laws, rather than on low-level details of the logical interpretation of constraints.

Another slight departure from Odersky et al.'s work lies in the fact that we have enriched the constraint language with type scheme introduction and instantiation forms, which were absent in the original presentation of

HM (X)

. To prevent this addition from affecting

HM (X)

, we require the constraints that appear in

HM (X)

typing judgements to have no free program identifiers. Please note that this does not prevent them from containing let forms; we shall in fact exploit this feature when establishing an equivalence between

HM (X)

and the type system presented in section 1.5 , where the new constraint forms are effectively used.

The type system

HM (X)

consists of a four-place judgement whose parameters are a constraint

C

, an environment

Γ

, an expression

t

, and a type scheme

σ

. A judgement is written

C, Γ ⊢ t : σ

and is read: under the assumptions

C

and

Γ

, the expression

t

has type

σ

. One may view

C

as an assumption about the judgement's free type variables and

Γ

as an assumption about t's free program identifiers. Please recall that

Γ

now contains constrained type schemes, and that

σ

is a constrained type scheme.

We would like the validity of a typing judgement to depend not on the

Figure 1-7: Typing rules for

HM (X)

syntax, but only on the meaning of its constraint assumption. We enforce this point of view by considering judgements equal modulo equivalence of their constraint assumptions. In other words, the typing judgements

C, Γ ⊢ t : σ

and

D, Γ ⊢ t : σ

are considered identical when

C \equiv D

holds. As a result, it does not make sense to analyze the syntax of a judgement's constraint assumption. A judgement is valid, or holds, if and only if it is derivable via the rules given in Figure 1-7. Please note that a valid judgement may involve an unsatisfiable constraint. A program t is well-typed within the environment

Γ

if and only if a judgement of the form

C, Γ ⊢ t : σ

holds for some satisfiable constraint

C

Let us now explain the rules. Like DM-VAR, HMX-VAR looks up the environment to determine the type scheme associated with the program identifier

x

. The constraint

C

that appears in the conclusion must be strong enough to guarantee that

σ

has an instance; this is expressed by the second premise. This technical requirement is used in the proof of Lemma 1.4.1. HMX-ABS, HMX-APP, and HMX-LET are identical to DM-ABS, DM-APP, and DM-LET, respectively, except that the assumption

C

is made available to every subderivation. We recall that the type

T

may be viewed as the type scheme

\forall \emptyset

[true].T (Definitions 1.2.18 and 1.3.2). As a result, types form a subset of type schemes, which implies that

Γ; z : T

is a well-formed environment and

C, Γ ⊢ t : T

a well-formed typing judgement. To understand HMX-GEN, it is best to first consider the particular case where

C

is true. This yields the following, simpler rule:

\begin{matrix} (HMX-GEN') & \frac{D, Γ ⊢ t : T \bar{x} # f t v (Γ)}{\exists \bar{x} \cdot D, Γ ⊢ t : \forall \bar{X} [D] . T} \end{matrix}

The second premise is identical to that of DM-GEN: the type variables that are generalized must not occur free within the environment. The conclusion forms the type scheme

\forall \bar{X} [D]

.T, where the type variables

\bar{X}

have become universally quantified, but are still subject to the constraint

D

. Please note that the type variables that occur free in

D

may include not only

\bar{X}

, but also other type variables, typically free in

Γ

. The rule's conclusion carries the constraint

\exists \bar{X} . D

, thus recording the requirement that the newly formed type scheme should have an instance; again, this is used in the proof of Lemma 1.4.1. HMX-GEN may be viewed as a more liberal version of HMX-GEN', whereby part of the current constraint, namely

C

, need not be copied if it does not concern the type variables that are being generalized, namely

\bar{X}

. This optimization is important in practice, because

C

may be very large. An intuitive explanation for its correctness is given by the constraint equivalence law

C

LETAND, which expresses the same optimization in terms of let constraints. Because

HM (X)

does not use let constraints, the optimization is hard-wired into the typing rule. HMX-INST allows taking an instance of a type scheme. The reader may be surprised to find that, contrary to DM-INST, it does not involve a type substitution. Instead, the rule merely drops the universal quantifier, which amounts to applying the identity substitution

\vec{X} \mapsto \vec{X}

. One should recall, however, that type schemes are considered equal modulo

α

-conversion, so it is possible to rename the type scheme's universal quantifiers prior to using HMX-INST. The reason why this provides sufficient expressive power appears in the proof of Theorem 1.4.7 below. The constraint

D

carried by the type scheme is recorded as part of the current constraint in HMX-INST's conclusion. The subsumption rule HMX-SUB allows a type

T

to be replaced at any time with an arbitrary supertype

T^{'}

. Because both

T

and

T^{'}

may have free type variables, whether

T \leq T^{'}

holds depends on the current assumption

C

, which is why the rule's second premise is an entailment assertion. An operational explanation of HMX-SUB is that it requires all uses of subsumption to be explicitly recorded in the current constraint. Please note that HMX-SUB remains a useful and necessary rule even when subtyping is interpreted as equality: then, it allows exploiting the type equations found in

C

. Last, HMXEXISTS allows the type variables that occur only within the current constraint to become existentially quantified. As a result, these type variables no longer occur free in the rule's conclusion; in other words, they have become local to the subderivation rooted at the premise. One may prove that the presence of HMX-EXISTS in the type system does not augment the set of well-typed programs, but does augment the set of valid typing judgements; it is a pleasant technical convenience. Indeed, because judgements are considered equal modulo constraint equivalence, constraints may be transparently simplified at any time. (By simplifying a constraint, we mean replacing it with an equiva-
lent constraint whose syntactic representation is considered simpler.) Bearing this fact in mind, one finds that an effect of rule HMX-Exists is to enable more simplifications: because constraint equivalence is a congruence,

C \equiv D

implies

\exists \bar{X} . C \equiv \exists \bar{X} . D

, but the converse does not hold in general. For instance, there is in general no way of simplifying the judgement

X \leq Y \leq Z, Γ ⊢ t : σ

, but if it is known that

Y

does not appear free in

Γ

σ

, then HMX-EXISTS allows deriving

\exists Y . (X \leq Y \leq Z), Γ ⊢ t : σ

, which is the same judgement as

x \leq Z, Γ ⊢ t : σ

. Thus, an interesting simplification has been enabled. Please note that

X \leq Y \leq Z \equiv X \leq Z

does not hold, while, according to C-ExTRans,

\exists Y

X \leq Y \leq Z) \equiv X \leq Z

does.

We now establish a few simple properties of the type system

HM (X)

. Our first lemma is a minor technical property.

1.4.1 Lemma:

C, Γ ⊢ t : σ

implies

C ⊩ \exists σ

The next lemma states that strengthening a judgement's constraint assumption preserves its validity. In other words, weakening a judgement preserves its validity. It is worth noting that in traditional presentations, which rely more heavily on type substitutions, the analogue of this result is a type substitution lemma; see for instance (Tofte, 1988, Lemma 2.7), (Leroy, 1992, Proposition 1.2), (Skalka and Pottier, 2002, Lemma 3.4). Here, the lemma further states that weakening a judgement does not alter the shape of its derivation, a useful property when reasoning by induction on type derivations.

1.4.2 Lemma [Weakening]: If

C^{'} ⊩ C

, then every derivation of

C, Γ ⊢ t : σ

may be turned into a derivation of

C^{'}, Γ ⊢ t : σ

with the same shape.

Proof: The proof is by structural induction on a derivation of

C, Γ ⊢ t : σ

. In each proof case, we adopt the notations of Figure 1-7.

Case HMX-VAR. The rule's conclusion is $C, Γ ⊢ x : σ$ . Its premises are $Γ (x) = σ$ (1) and $C ⊩ \exists σ$ (2). By hypothesis, we have $C^{'} ⊩ C$ (3). By transitivity of entailment, (3) and (2) imply $C^{'} ⊩ \exists σ$ (4). By HMX-VAR, (1) and (4) yield $C^{'}, Γ ⊢ x : σ$ .
Cases HMX-ABS, HMX-App, HMX-LET. By the induction hypothesis and by HMX-ABS, HMX-APP, or HMX-LET, respectively.
Case HMX-GEn. The rule's conclusion is $C \land \exists \bar{x} . D, Γ ⊢ t : \forall \bar{x} [D]$ .T. Its premises are $C \land D, Γ ⊢ t : T$ (1) and $\bar{x} # f t v (C, Γ)$ (2). By hypothesis, we have $C^{'} ⊩ C \land \exists \bar{X} . D$ (3). We may assume, w.l.o.g., $\bar{X} # f t v (C^{'})$ (4). Applying the induction hypothesis to (1) and to the entailment assertion $C^{'} \land C \land D ⊩ C \land D$ , we obtain $C^{'} \land C \land D, Γ ⊢ t : T$ (5). By HMX-GEN, applied to (5), (2) and (4), we get $C^{'} \land C \land \exists \bar{x} . D, Γ ⊢ t : \forall \bar{x} [D] . T$ (6). By (3) and C-Dup, the constraints $C^{'} \land C \land \exists \bar{x} . D$ and $C^{'}$ are equivalent, so (6) is the goal $C^{'}, Γ ⊢ t : \forall \bar{x} [D]$ . .T.
Case HmX-Inst. The rule's conclusion is $C \land D, Γ ⊢ t$ : T. Its premise is $C, Γ ⊢ t : \forall \bar{X} [D] . T$ (1). By hypothesis, $C^{'}$ entails $C \land D$ (2). Because (2) implies $C^{'} ⊩ C$ , the induction hypothesis may be applied to (1), yielding $C^{'}, Γ ⊢ t : \forall \bar{x} [D] . T$ (3). By HmX-Inst, we obtain $C^{'} \land D, Γ ⊢ t : T$ (4). Because (2) implies $C^{'} \equiv C^{'} \land D$ , (4) is the goal $C^{'}, Γ ⊢ t : T$ .
Case HmX-Sub. The rule's conclusion is $C, Γ ⊢ t : T^{'}$ . Its premises are $C, Γ ⊢ t : T$ (1) and $C ⊩ T \leq T^{'}$ (2). By hypothesis, we have $C^{'} ⊩ C$ (3). Applying the induction hypothesis to (1) and (3) yields $C^{'}, Γ ⊢ t : T$ (4). By transitivity of entailment, (3) and (2) imply $C^{'} ⊩ T \leq T^{'}$ (5). By HMX-SuB, (4) and (5) yield $C^{'}, Γ ⊢ t : T^{'}$ .
Case HmX-Exists. The rule's conclusion is $\exists \bar{x} . C, Γ ⊢ t : σ$ . Its premises are $C, Γ ⊢ t : σ (1)$ and $\bar{x} # f t v (Γ, σ) (2)$ . By hypothesis, we have $C^{'} ⊩$ $\exists \bar{X} . C$ (3). We may assume, w.l.o.g., $\bar{x} # f t v (C^{'})$ (4). Applying the induction hypothesis to (1) and to the entailment assertion $C^{'} \land C ⊩ C$ , we obtain $C^{'} \land C, Γ ⊢ t : σ$ (5). By HmX-Exists, (5) and (2) yield $\exists \bar{X} . (C^{'} \land C), Γ ⊢$ $t : σ$ (6). By (4) and C-ExAnd, the constraint $\exists \bar{X}$ . $(C^{'} \land C)$ is equivalent to $C^{'} \land \exists \bar{X}$ . $C$ , which, by (3) and C-Dup, is equivalent to $C^{'}$ . Thus, (6) is the goal $C^{'}, Γ ⊢ t : σ$ .

We do not give a direct type soundness proof for

HM (X)

. Instead, in section 1.5 , we prove that it is equivalent to another type system, which later is itself proven sound. A direct type soundness result, based on a denotational semantics, may be found in (Odersky, Sulzmann, and Wehr, 1999a). Another type soundness proof, which follows Wright and Felleisen's syntactic approach (1994b), appears in (Skalka and Pottier, 2002). Last, a hybrid approach, which combines some of the advantages of the previous two, is given in (Pottier, 2001a).

An alternate presentation of $H M (X)$

The presentation of

H M (X)

given in Figure 1-7 has only four syntax-directed rules out of eight. It is a good specification of the type system, but it is far from an algorithmic description. As a first step towards such a description, we provide an alternate presentation of

HM (X)

, where generalization is performed only at let expressions and instantiation takes place only at references to program identifiers (Figure 1-8). It has the property that all judgements are of the form

C, Γ ⊢ t : T

, rather than

C, Γ ⊢ t : σ

. The following theorem states that the two presentations are indeed equivalent.

1.4.3 Theorem:

C, Γ ⊢ t : T

is derivable via the rules of Figure 1-8 if and only if it is a valid

HM (X)

judgement.

Figure 1-8: An alternate presentation of

H M (X)

This theorem shows that the rule sets of Figures 1-7 and 1-8 derive the same monomorphic judgements, that is, the same judgements of the form

C, Γ ⊢ t : T

. The fact that judgements of the form

C, Γ ⊢ t : σ

, where

σ

is a not a monotype, cannot be derived using the new rule set is a technical simplification, without deep significance; the first two exercises below shed some light on this issue.

1.4.4 EXERCISE

[⋆ ⋆]

: Show that both rule sets lead to the same set of well-typed programs.

1.4.5 ExERcISE

[⋆ ⋆

]: Show that, if HMX-GEN is added to the rule set of Figure 18 , then both rule sets derive exactly the same judgements.

1.4.6 EXERCISE

[⋆ ⋆ ⋆, ↛]

: Show that it is possible to simplify the presentation of Damas and Milner's type system in an analogous manner. That is, define an alternate set of typing rules for DM, which allows deriving judgements of the form

Γ ⊢ t : T

; then, show that this new rule set is equivalent to the previous one, in the same sense as above. Which auxiliary properties of DM does your proof require? A solution is given in (Clément, Despeyroux, Despeyroux, and Kahn, 1986).

Relating $H M (X)$ with Damas and Milner's type system

In order to explain our interest in

HM (X)

, we wish to show that it is more general than Damas and Milner's type system. Since

HM (X)

really is a family of type systems, we must make this statement more precise. First, every member of the

H M (X)

family contains DM. Conversely, DM contains

H M (=)

, the
constraint-based type system obtained by specializing

HM (X)

to the setting of an equality-only syntactic model.

The first of these assertions is easy to prove, because the mapping from DM judgements to

HM (X)

judgements is essentially the identity: every valid DM judgement may be viewed as a valid

HM (X)

judgement under the trivial assumption true. This statement relies on the fact that the DM type scheme

\forall \bar{X}

T

is identified with the constrained type scheme

\forall \bar{X}

[true].T, so DM type schemes (resp. environments) form a subset of

HM (X)

type schemes (resp. environments). Its proof is routine, except perhaps in the case of DM-INST, where it is shown how the effect of applying a substitution in DM is emulated by strengthening the current constraint in

HM (X)

1.4.7 Theorem: If

Γ ⊢ t : S

holds in

D M

, then true,

Γ ⊢ t : S

holds in

HM (X)

Proof: The proof is by structural induction on a derivation of

Γ ⊢ t : S

. In each proof case, we adopt the notations of Figure 1-3.

Case DM-VAR. The rule's conclusion is $Γ ⊢ x : S$ . Its premise is $Γ (x) =$ $S$ (1). By definition and by $C - E x *$ , the constraint $\exists S$ is equivalent to true. By applying HMX-VAR to (1) and to the assertion true $⊩$ true, we obtain true, $Γ ⊢ x : S$ .
Cases DM-ABS, DM-ApP, DM-LET. By the induction hypothesis and by HMX-ABS, HMX-APP or HMX-LET, respectively.

\circ

Case DM-GEn. The rule's conclusion is

Γ ⊢ t : \forall \bar{x}

.T. Its premises are

Γ ⊢ t : T (1)

and

\bar{X} # f t v (Γ)

(2). Applying the induction hypothesis to (1) yields true,

Γ ⊢ t : T

(3). Furthermore, (2) implies

\bar{X} # f t v (t r u e, Γ)

(4). By HMX-GEN, (3) and (4) yield true,

Γ ⊢ t : \forall \bar{x} [

true].T.

Case Dm-Inst. The rule's conclusion is $Γ ⊢ t : [\vec{x} \mapsto \vec{T}] T$ . Its premise is $Γ ⊢ t : \forall \bar{X} . T$ (1). We may assume, w.l.o.g., $\bar{X} # f t v (Γ, \bar{T})$ (2). Applying the induction hypothesis to (1) yields true, $Γ ⊢ t : \forall \bar{X} [$ true].T (3). By HMXInst, (3) implies true, $Γ ⊢ t : T$ (4). By Lemma 1.4.2, we may weaken this judgement so as to obtain $\vec{x} = \vec{T}, Γ ⊢ t : T$ (5). Using C-EQ, C-ExTrans, and C-ExAnd, it is possible to establish $\vec{X} = \vec{T} ⊩ T = [\vec{X} \mapsto \vec{T}] T$ (6). Applying HMX-SuB to (5) and (6), we find $\vec{x} = \vec{T}, Γ ⊢ t : [\vec{X} \mapsto \vec{T}] T$ (7). Last, (2) implies $\bar{X} # f t v (Γ, [\vec{X} \mapsto \vec{T}] T)$ (8). Applying HMX-EXisTs to (7) and (8), we obtain $\exists \bar{X} . (\vec{X} = \vec{T}), Γ ⊢ t : [\vec{X} \mapsto \vec{T}] T$ (9). By (2) and C-NAME, the constraint $\exists \bar{X} . (\vec{X} = \vec{T})$ is equivalent to true, so (9) is the goal.

We are now interested in proving that

H M (=)

, as defined above, is contained within DM. To this end, we must translate every

H M (=)

judgement to a DM judgement. It quickly turns out that this is possible if the original judgement's constraint assumption is satisfiable.

We begin by explaining how an

H M (=)

is translated into a DM type scheme. Such a translation is made possible by the fact that the definition of

HM (=)

assumes an equality-only syntactic model. Indeed, in that setting, every satisfiable constraint admits a most general unifier (Definition 1.3.41), whose properties we make essential use of.

In fact, we must not only translate a type scheme, but also apply a type substitution to it. Instead of separating these steps, we perform both at once, and parameterize the translation by a type substitution

θ

. (It does not appear that separating them would help.) The definition of

[[σ {]]}_{θ}

is somewhat involved: it is given in the statement of the following lemma, whose proof establishes that the definition is indeed well-formed.

1.4.8 Lemma: Consider a type scheme

σ

and an idempotent type substitution

θ

such that

f t v (σ) \subseteq dom (θ)

(1) and

\exists θ ⊩ \exists σ

(2). Write

σ = \forall \bar{x} [D]

.T, where

\bar{x} # θ

(3). Then, there exists a type substitution

θ^{'}

such that

θ^{'}

extends

θ, dom (θ^{'})

dom (θ) \cup \bar{X}

, and

θ^{'}

is a most general unifier of

\exists θ \land D

. Let

\bar{Y} = f tv (θ^{'} (\bar{X})) ∖ range (θ)

. Then, the translation of

σ

under

θ

, written

[[σ {]]}_{θ}

, is the DM type scheme

\forall \bar{Y} \cdot θ^{'} (T)

. This is a well-formed definition. Furthermore,

f t v ([[σ {]]}_{θ}) \subseteq range (θ)

holds.

Proof: By (2),

\exists θ

is equivalent to

\exists θ \land \exists σ

, which may be written

\exists θ \land \exists \bar{X} . D

. By (3) and C-ExAnd, this is

\exists \bar{x}

(\exists θ \land D)

. Thus, because

θ

is a most general unifier of

\exists θ, θ

is also a most general unifier of

\exists \bar{X}

(\exists θ \land D)

(4). Furthermore,

ftv (\exists \bar{X} . (\exists θ \land D))

ftv (\exists θ \land \exists σ)

, which by definition of

\exists θ

and by (1) is a subset of

dom (θ) (5)

. By (4), (3), (5), and Lemma 1.3.45, there exists a type substitution

θ^{'}

such that

θ^{'}

extends

θ (6)

and

θ^{'}

is a most general unifier of

\exists θ \land D (7)

and

dom (θ^{'}) = dom (θ) \cup \bar{X} (8)

Let us now define

\bar{Y} = f t v (θ^{'} (\bar{X})) ∖ range (θ)

and

[[σ {]]}_{θ} = \forall \bar{Y} \cdot θ^{'} (T)

. By (1), we have

f t v (T) \subseteq \bar{X} \cup dom (θ)

. Applying

θ^{'}

and exploiting (6), we find

f t v (θ^{'} (T)) \subseteq

f t v (θ^{'} (\bar{X})) \cup range (θ)

, which by definition of

\bar{Y}

may be written

f t v (θ^{'} (T)) \subseteq

\bar{Y} \cup

range

(θ)

. Subtracting

\bar{Y}

on each side, we find

ftv ([[σ {]]}_{θ}) \subseteq range (θ) (9)

To show that the definition of

[[σ {]]}_{θ}

is valid, there remains to show that it does not depend on the choice of

\bar{X}

θ^{'}

. To prove the former, it suffices to establish

\bar{X} # f t v ([[σ {]]}_{θ})

, which indeed follows from (3) and (9). As for the latter, because of the constraints imposed by (6), (7), and (8), and by Lemma 1.3.44, distinct choices of

θ^{'}

may differ only by a renaming of

f t v (θ^{'} (\bar{X})) ∖ range (θ)

, that is,

\bar{Y}

. So, we must check

\bar{Y} # f t v ([[σ {]]}_{θ})

, which holds by definition.

Please note that if

σ

is in fact a type

T

, where

f t v (T) \subseteq dom (θ)

, then

\bar{X}

is empty, so

θ^{'}

θ, \bar{Y}

is empty, and

[[T {]]}_{θ} = θ (T)

. In other words, the translation of a type under

θ

is its image through

θ

. More generally, the translation of an unconstrained type scheme (that is, a type scheme whose constraint is true) is its image through

θ

, as stated by the following exercise.

1.4.9 EXERCISE

[⋆ ⋆, ↛]

: Prove that

[[\forall \bar{X} . T {]]}_{θ}

, when defined, is

θ (\forall \bar{X} . T)

The translation becomes more than a mere type substitution when applied to a nontrivial constrained type scheme. Some examples of this situation are given below.

1.4.10 Example: Let

σ = \forall X Y [X = Y \to Y]

.X. Let

θ

be the identity substitution. The type scheme

σ

is closed and the constraint

\exists σ

is equivalent to true, so

[[σ {]]}_{θ}

is defined. We must find a type substitution

θ^{'}

whose domain is XY and that is a most general unifier of

X = Y \to Y

. All such substitutions are of the form

[X \mapsto (Z \to Z), Y \mapsto Z]

, where

Z

is fresh. We have

f t v (θ^{'} (X Y)) = Z

, whence

[[σ {]]}_{θ} = \forall Z . Z \to Z

. Note that the choice of

Z

does not matter, since it is bound in

[[σ {]]}_{θ}

. Roughly speaking, the effect of the translation was to replace the body

X

of the constrained type scheme with its most general solution under the constraint

X = Y \to Y

Let

σ = \forall {X Y}_{1} [X = Y_{1} \to Y_{2}]

.X. Let

θ = [Y_{2} \mapsto Z_{2}]

. We have

f t v (σ) =

Y_{2} \subseteq dom (θ)

. The constraint

\exists σ

is equivalent to true, so

[[σ {]]}_{θ}

is defined. We must find a type substitution

θ^{'}

whose domain is

{X Y}_{1} Y_{2}

that extends

θ

and that is a most general unifier of

X = Y_{1} \to Y_{2}

. All such substitutions are of the form

[X \mapsto (Z_{1} \to Z_{2}), Y_{1} \mapsto Z_{1}, Y_{2} \mapsto Z_{2}]

, where

Z_{1}

is fresh. We have

ftv (θ^{'} ({X Y}_{1})) ∖ range (θ) = Z_{1} Z_{2} ∖ Z_{2} = Z_{1}

, whence

[[σ {]]}_{θ} = \forall Z_{1} \cdot Z_{1} \to Z_{2}

. The type variable

Z_{2}

is not universally quantified - even though it appears in the image of

X

, which was universally quantified in

σ

-because

Z_{2}

is the image of

Y_{2}

, which was free in

σ

Before attacking the main theorem, let us establish a couple of technical properties of the translation. First,

[[σ {]]}_{θ}

is insensitive to the behavior of

θ

outside

ftv (σ)

, a natural property, since our informal intent is for

θ

to be applied to

σ

1.4.11 Lemma: If

θ_{1}

and

θ_{2}

coincide on

f t v (σ)

, then

[[σ {]]}_{θ_{1}}

and

[[σ {]]}_{θ_{2}}

are either both undefined, or both defined and identical.

Second, if

C ⊩ σ ⪯ T^{'}

holds, then the translations of

σ

and

T^{'}

under a most general unifier of

C

are in Damas and Milner's instance relation. One might say, roughly speaking, that the instance relation is preserved by the translation.

1.4.12 Lemma: Let

f t v (σ, T^{'}) \subseteq dom (θ)

(1) and

\exists θ ⊩ \exists σ

(2). Let

\exists θ ⊩ σ ⪯ T^{'}

(3). Then,

θ (T^{'})

is an instance of the DM type scheme

[[σ {]]}_{θ}

Proof: Write

σ = \forall \bar{X} [D] . T

, where

\bar{X} # θ

(4) and

\bar{X} # f t v (T^{'})

(5). By (1),

(2)

, and (4), one may define

θ^{'}, \bar{Y}

, and

[[σ {]]}_{θ}

exactly as in the statement of Lemma 1.4.8. By (5) and Definition 1.3.3, (3) is synonymous with

\exists θ ⊩ \exists \bar{X}

D \land

T = T^{'}

). Reasoning in the same manner as in the first paragraph of the proof of Lemma 1.4.8, we find that there exists a type substitution

θ^{''}

such that

θ^{''}

extends

θ, dom (θ^{''})

dom (θ) \cup \bar{X}

, and

θ^{''}

is a most general unifier of

\exists θ \land D \land T = T^{'}

We have

dom (θ^{'}) = dom (θ^{''}) (6)

. Furthermore,

θ^{'}

is a most general unifier of

\exists θ \land D

, while

θ^{''}

is a most general unifier of

\exists θ \land D \land T = T^{'}

, which implies

\exists θ^{''} ⊩ \exists θ^{'} (7)

. By Lemma 1.3.39,

θ^{''}

refines

θ^{'}

. That is, there exists a type substitution

φ

such that

θ^{''}

is the restriction of

φ \circ θ^{'}

dom (θ) \cup \bar{x} (8)

. We may require

dom (φ) \subseteq range (θ) \cup f t v (θ^{'} (\bar{X})) (9)

without compromising (8).

Consider

X \in dom (θ)

. Because

θ^{''}

extends

θ

, we have

θ^{''} (X) = θ (X) (10)

. Furthermore, by (8), we have

θ^{''} (X) = (φ \circ θ^{'}) (x) = (φ \circ θ) (X) (11)

. Using (10) and (11), we find

θ (X) = φ (θ (X))

. Because this holds for every

X \in dom (θ)

φ

must be the identity over range

(θ)

; that is,

dom (φ)

# range

(θ)

(12) holds. Combining (9) and (12), we find

dom (φ) \subseteq f t v (θ^{'} (\bar{X})) ∖ range (θ)

, that is,

dom (φ) \subseteq \bar{Y} (13)

By construction of

θ^{''}

, we have

\exists θ^{''} ⊩ T = T^{'}

. By Lemma 1.3.29, this implies

θ^{''} (\exists θ^{''}) ⊩ θ^{''} (T) = θ^{''} (T^{'})

, which by Lemma 1.3.42 may be read true

⊩ θ^{''} (T) =

θ^{''} (T^{'})

. By Lemma 1.3.32,

θ^{''} (T)

and

θ^{''} (T^{'})

coincide. Because by (1)

f t v (T)

is a subset of

dom (θ) \cup \bar{X}

and by (8), the former may be written

φ (θ^{'} (T))

. By (1) and because

θ^{''}

extends

θ

, the latter is

θ (T^{'})

. Thus, we have

φ (θ^{'} (T)) = θ (T^{'})

. Together with (13), this establishes that

θ (T^{'})

is an instance of

\forall \bar{Y} . θ^{'} (T)

, that is,

[[σ {]]}_{θ}

We extend the translation to environments as follows.

[[\emptyset {]]}_{θ}

\emptyset

. If

\exists θ ⊩ \exists σ

holds, then

[[Γ; x : σ {]]}_{θ}

[[Γ {]]}_{θ}; x : [[σ {]]}_{θ}

, otherwise it is

[[Γ {]]}_{θ}

. Notice that

[[Γ {]]}_{θ}

contains fewer bindings than

Γ

, which ensures that bindings

x : σ

for which

\exists θ ⊩ \exists σ

does not hold will not be used in the translation. Please note that

[[Γ {]]}_{θ}

is defined when

f t v (Γ) \subseteq dom (θ)

holds.

We are now ready to prove the main theorem. Please note that, by requiring

θ

to be a most general unifier of

C

, we also require

C

to be satisfiable. Judgements that carry an unsatisfiable constraint cannot be translated.

1.4.13 Theorem: Let

C, Γ ⊢ t : σ

hold in

HM (=)

. Let

θ

be a most general unifier of

C

such that

f t v (Γ, σ) \subseteq dom (θ)

. Then,

[[Γ {]]}_{θ} ⊢ t : [[σ {]]}_{θ}

holds in DM.

Proof: Let us first remark that, by Lemma 1.4.1, we have

C ⊩ \exists σ

. This may be written

\exists θ ⊩ \exists σ

, which guarantees that

[[σ {]]}_{θ}

is defined. The proof is by structural induction on an

HM (=)

typing derivation. We assume that the derivation is expressed in terms of the rules of Figure 1-8, but split HMDLETGEN into HMX-LET and HMX-GEN for the sake of readability.

Case HmD-VARInst. The rule's conclusion is $C \land D, Γ ⊢ x : T$ . By hypothesis, $θ$ is a most general unifier of $C \land D (1)$ , and $ftv (T) \subseteq dom (θ)$ (2)
holds. The rule's premise is $Γ (x) = σ$ (3), where $σ$ stands for $\forall \bar{x} [D]$ .T. By (1), we have $\exists θ \equiv C \land D ⊩ D ⊩ \exists \bar{x} . D \equiv \exists σ$ (4). Furthermore, we have $f t v (σ) \subseteq f t v (Γ) \subseteq dom (θ)$ (5). These facts show that $[[σ {]]}_{θ}$ is defined. Together with (3), this implies $[[Γ {]]}_{θ} (x) = [[σ {]]}_{θ}$ . By DM-VAR, $[[Γ {]]}_{θ} ⊢ x : [[σ {]]}_{θ}$ (6) follows. Now, by Lemma 1.3.19, we have $D ⊩ σ ⪯ T$ , which, combined with $\exists θ ⊩ D$ , yields $\exists θ ⊩ σ ⪯ T$ (7). By (7), (4), (5), (2), and Lemma 1.4.12, we find that $θ (T)$ is an instance of $[[σ {]]}_{θ}$ . Thus, applying DM-INsT to (6) yields $[[Γ {]]}_{θ} ⊢ t : θ (T)$ .
Case HmD-ABs. The rule's conclusion is $C, Γ ⊢ λ z . t : T \to T^{'}$ . Its premise is $C, (Γ; z : T) ⊢ t : T^{'}$ . Applying the induction hypothesis to it yields $[[Γ {]]}_{θ}; z$ : $θ (T) ⊢ t : θ (T^{'})$ . By DM-ABS, this implies $[[Γ {]]}_{θ} ⊢ λ$ z.t $: θ (T) \to θ (T^{'})$ , that is, $[[Γ {]]}_{θ} ⊢ λ z . t : θ (T \to T^{'})$ .
Case HMd-Apr. By an extension of $dom (θ)$ to include $f t v (T)$ , by the induction hypothesis, and by DM-APP.
Case HMX-Let. By an extension of $dom (θ)$ to include $f t v (σ)$ , by the induction hypothesis, and by DM-LET.
Case HmX-GEn. The rule's conclusion is $C \land \exists σ, Γ ⊢ t : σ$ , where $σ$ stands for $\forall \bar{X} [D]$ .T. By hypothesis, $θ$ is a most general unifier of $C \land \exists σ$ (1), and $f t v (Γ, σ) \subseteq dom (θ) (2)$ holds. The rule's premises are $C \land D, Γ ⊢ t : T (3)$ and $\bar{X} # f t v (C, Γ)$ (4). We may further assume, w.l.o.g., $\bar{X} # θ$ (5). Given (1), (2), and (5), we may define $θ^{'}$ and $\bar{Y}$ exactly as in Lemma 1.4.8. Then, $θ^{'}$ is a most general unifier of $\exists θ \land D$ , that is, $C \land D$ . Furthermore, $dom (θ^{'})$ is $dom (θ) \cup \bar{x}$ , which by (2) is a superset of $f t v (Γ, T)$ . Thus, the induction hypothesis applies to $θ^{'}$ and to (3), yielding $[[Γ {]]}_{θ^{'}} ⊢ t : θ^{'} (T)$ . Because $θ^{'}$ extends $θ$ , by (2) and by Lemma 1.4.11, this may be read $[[Γ {]]}_{θ} ⊢ t : θ^{'} (T)$ (6). According to Lemma 1.4.8, we have $f t v ([[Γ {]]}_{θ}) \subseteq$ range $(θ)$ , which by construction of $\bar{Y}$ implies $\bar{Y} # ftv ([[Γ {]]}_{θ})$ (7). By DM-GEN, (6) and (7) yield $[[Γ {]]}_{θ} ⊢ t : \forall \bar{Y} \cdot θ^{'} (T)$ , that is, $[[Γ {]]}_{θ} ⊢ t : [[σ {]]}_{θ}$ .
Case HmD-Sub. The rule's conclusion is $C, Γ ⊢ t : T^{'}$ . By hypothesis, $θ$ is a most general unifier of $C (1)$ , and $f t v (Γ, T^{'}) \subseteq dom (θ)$ (2) holds. The goal is $[[Γ {]]}_{θ} ⊢ t : θ (T^{'}) (3)$ . The rule's premises are $C, Γ ⊢ t : T (4)$ and $C ⊩ T = T^{'}$ (5). We may assume, w.l.o.g., ftv $(T) # range (θ)$ (6). Then, by (6) and Lemma 1.3.43, we may extend the domain of $θ$ , so as to achieve $f t v (T) \subseteq dom (θ) (7)$ , without compromising (1) or (2) or affecting the goal (3). By (1), (2), and (7), the induction hypothesis applies to (4), yielding $[[Γ {]]}_{θ} ⊢ t : θ (T) (8)$ . Now, thanks to (1), (5) may be $read \exists θ ⊩ T = T^{'}$ , which by Lemmas 1.3 .29 and 1.3.42 implies true $⊩ θ (T) = θ (T^{'})$ . Then, Lemma 1.3.32 shows that $θ (T)$ and $θ (T^{'})$ coincide. As a result, (8) is the goal (3).

\circ

Case HmD-ExisTs. The rule's conclusion is

\exists \bar{X} . C, Γ ⊢ t

: T. By hypothesis,

θ

is a most general unifier of

\exists \bar{X} . C (1)

, and

f t v (Γ, T) \subseteq dom (θ)

(2) holds. The
rule's premises are

C, Γ ⊢ t : T (3)

and

\bar{X} # f t v (Γ, T)

. We may assume, w.l.o.g.,

\bar{x} # θ

(4). As in the previous case, we may extend the domain of

θ

to guarantee

ftv (\exists \bar{X} . C) \subseteq dom (θ)

(5). By (1), (4), (5), and Lemma 1.3.45, there exists a type substitution

θ^{'}

such that

θ^{'}

extends

θ

(6) and

θ^{'}

is a most general unifier of

C

. Applying the induction hypothesis to

θ^{'}

and to (3) yields

[[Γ {]]}_{θ^{'}} ⊢ t : θ^{'} (T)

. By (2), (6), and Lemma 1.4.11, this may be read

[[Γ {]]}_{θ} ⊢ t : θ (T)

Together, Theorems 1.4.7 and 1.4.13 yield a precise correspondence between

D M

and

HM (=)

: there exists a compositional translation from each to the other. In other words, they may be viewed as two equivalent formulations of a single type system. One might also say that

H M (=)

is a constraint-based formulation of DM. Furthermore, Theorem 1.4.7 states that every member of the

HM (X)

family is an extension of DM. This explains our double interest in

H M (X)

, as an alternate formulation of

D M

, which we believe is more pleasant, for reasons already discussed, and as a more expressive framework.

1.5 A purely constraint-based type system: $PCB (X)$

In the previous section, we have presented

HM (X)

, an elegant constraintbased extension of Damas and Milner's type system. However,

HM (X)

, as described there, suffers from a drawback. A typing judgement involves both a constraint, which represents an assumption about its free type variables, and an environment, which represents an assumption about its free program identifiers. At a let node, HMD-LETGEN turns a part of the current constraint, namely

D

, into a type scheme, namely

\forall \bar{x} [D] . T

, and stores it into the environment. Then, at every occurrence of the let-bound variable, HMD-VARINST retrieves this type scheme from the environment and adds a copy of

D

back to the current constraint. In practice, it is important to simplify the type scheme

\forall \bar{X} [D] . T

before it is stored in the environment, because it would be inefficient to copy an unsimplified constraint. In other words, it appears that, in order to preserve efficiency, constraint generation and constraint simplification cannot be separated.

Of course, in practice, it is not difficult to intermix these phases, so the problem is not technical, but pedagogical. Indeed, we argued earlier that it is natural and desirable to separate them. Type scheme introduction and elimination constraints, which we introduced in Section 1.3 but did not use in the specification of

HM (X)

, are intended as a means of solving this problem. In the present section, we exploit them to give a novel formulation of

H M (X)

, which no longer requires copying constraints back and forth between the environment and the constraint assumption. In fact, the environment is

$\frac{C ⊩ x ⪯ T}{C ⊢ x : T}$	$(V A R)$	$\frac{C_{1} ⊢ t_{1} : T_{1} C_{2} ⊢ t_{2} : T_{2}}{let z : \forall V [C_{1}] \cdot T_{1} in C_{2}}$	(LET)
$\frac{C ⊢ t : T^{'}}{}$
$\frac{let z = t_{1} in t_{2} : T_{2}}{}$
$\frac{C_{1} ⊢ t_{1} : T \to T^{'} C_{2} ⊢ t_{2} : T}{C_{1} \land C_{2} ⊢ t_{1} t_{2} : T^{'}}$	$(A P P)$	$\frac{C ⊢ t : T}{C \land T \leq T^{'} ⊢ t : T^{'}}$	(SUB)
		$\frac{C ⊢ t : T \bar{x} # f t v (T)}{\exists \bar{x} \cdot C ⊢ t : T}$	(ExISTS)

Figure 1-9: Typing rules for

PCB (X)

suppressed altogether: taking advantage of the new constraint forms, we encode information about program identifiers within the constraint assumption.

Presentation

We now employ the full constraint language (Section 1.3). Typing judgements take the form

C ⊢ t

T

, where

C

may have free type variables and free program identifiers. The rules that allow deriving such judgements appear in Figure 1-9. As before, we identify judgements up to constraint equivalence.

Let us review the rules. VAR states that

x

has type

T

under any constraint that entails

x ⪯ T

. Note that we no longer consult the type scheme associated with

x

in the environment-indeed, there is no environment. Instead, we let the constraint assumption record the fact that the type scheme should admit

T

as one of its instances. Thus, in a judgement

C ⊢ t : T

, any program identifier that occurs free within

t

typically also occurs free within

C

. ABs requires the body

t

of a

λ

-abstraction to have type

T^{'}

under assumption

C

. Although no explicit assumption about

z

appears in the premise,

C

typically contains a number of instantiation constraints bearing on

z

, of the form

z ⪯ T_{i}

. In the rule's conclusion,

C

is wrapped within the prefix let

z : T

[

, where

T

is the type assigned to

z

. This effectively requires every

T_{i}

to denote a supertype of

T

, as desired. Please note that

z

does not occur free in the constraint let

z : T

C

, which is natural, since it does not occur free in

λ

z.t. App exhibits a minor stylistic difference with respect to HMX-APP: its constraint assumption is split between its premises. It is not difficult to prove that, when weakening holds (see Lemma 1.5.2 below), this choice does not affect the set of valid judgements. This new presentation encourages reading the rules in Figure 1-9 as the specification of an algorithm, which, given

t

and

T

, pro-
duces

C

such that

C ⊢ t : T

holds. In the case of App, the algorithm invokes itself recursively for each of the two subexpressions, yielding the constraints

C_{1}

and

C_{2}

, then constructs their conjunction. LET is analogous to ABS: by wrapping

C_{2}

within a let prefix, it gives meaning to the instantiation constraints bearing on

z

within

C_{2}

. The difference is that

z

may now be assigned a type scheme, as opposed to a monotype. An appropriate type scheme is built in the most straightforward manner from the constraint

C_{1}

and the type

T_{1}

that describe

t_{1}

. All of the type variables that appear free in the left-hand premise are generalized, hence the notation

\forall V [C_{1}] . T_{1}

, which is a convenient shorthand for

\forall ftv (C_{1}, T_{1}) [C_{1}] . T_{1}

. The side-condition that "type variables that occur free in the environment must not be generalized", which was present in

D M

and

HM (X)

, naturally disappears, since judgements no longer involve an environment. SUB again exhibits a minor stylistic difference with respect to HMX-SUB: the comments made about APp above apply here as well. ExISTS is essentially identical to HMX-EXISTS.

In the standard specification of

HM (X)

, HMD-ABS and HMD-LET GEN accumulate information in the environment. Through the environment, this information is made available to HMD-VARINST, which retrieves and copies it. Here, instead, no information is explicitly transmitted. Where a program identifier is bound, a type scheme introduction constraint is built; where a program identifier is used, a type scheme instantiation constraint is produced. The two are related only by our definition of the meaning of constraints.

The reader may be puzzled by the fact that LET allows all type variables that occur free in its left-hand premise to be generalized. The following exercise sheds some light on this issue.

1.5.1 Exercise [

⋆

, Recommended]: Build a type derivation for the expression

λ z_{1}

. let

z_{2} = z_{1}

z_{2}

within

PCB (X)

. Draw a comparison with the solution of Exercise 1.2.21.

The following lemma is an analogue of Lemma 1.4.2.

1.5.2 Lemma [Weakening]: If

C^{'} ⊩ C

, then every derivation of

C ⊢ t : T

may be turned into a derivation of

C^{'} ⊢ t : T

with the same shape.

Proof: The proof is by structural induction on a derivation of

C ⊢ t : T

. In each proof case, we adopt the notations of Figure 1-9.

Case VAR. By transitivity of entailment.
Case ABs. The rule's conclusion is let $z : T$ in $C ⊢ λ$ z.t : $T \to T^{'} (1)$ . By hypothesis, we have $C^{'} ⊩$ let $z : T$ in $C$ (2). We may assume, w.l.o.g., $z \notin f p i (C^{'}) (3)$ . The rule's premise is $C ⊢ t : T^{'} (4)$ . Applying the induction hypothesis to (4) yields $C \land C^{'} ⊢ t : T^{'}$ , which by ABs implies let $z : T$ in $(C \land$
$C^{'}) ⊢ λ$ z.t : $T \to T^{'} (5)$ . By (3) and C-INAND*, let $z : T$ in $(C \land C^{'})$ is equivalent to (let $z : T$ in $C$ ) $\land C^{'}$ , which by (2) and $C$ -Dup is equivalent to $C^{'}$ . Thus, (5) is the goal $C^{'} ⊢ λ z$ .t : $T \to T^{'}$ .
Case APp. By applying the induction hypothesis to each premise, using the fact that $C^{'} ⊩ C_{1} \land C_{2}$ implies $C^{'} ⊩ C_{1}$ and $C^{'} ⊩ C_{2}$ .
Case LET. Analogous to the case of ABS. The induction hypothesis is applied to the second premise only.
Case Sub. Analogous to the case of Apr.
Case ExISTs. See the corresponding case in the proof of Lemma 1.4.2.

Relating $PCB (X)$ with $HM (X)$

Let us now provide evidence for our claim that

PCB (X)

is an alternate presentation of

HM (X)

. The next two theorems define an effective translation from

HM (X)

PCB (X)

and back.

The first theorem states that if, within

HM (X)

t

has type

T

under assumptions

C

and

Γ

, then, within

PCB (X)

t

also has type

T

, under some assumption

C^{'}

. The relationship

C ⊩

let

Γ

C^{'}

states that

C

entails the residual constraint obtained by confronting

Γ

, which provides information about the free program identifiers in

t

, with

C^{'}

, which contains instantiation constraints bearing on these program identifiers. The statement requires

C

and

Γ

to have no free program identifiers, which is natural, since they are part of an

HM (X)

judgement. The hypothesis

C ⊩ \exists Γ

excludes the somewhat pathological situation where

Γ

contains constraints not apparent in

C

. This hypothesis vanishes when

Γ

is the initial environment; see Definition 1.7.3.

1.5.3 Theorem: Let

C ⊩ \exists Γ

. Assume

f p i (C, Γ) = \emptyset

. If

C, Γ ⊢ t : T

holds in

HM (X)

, then there exists a constraint

C^{'}

such that

C^{'} ⊢ t : T

holds in

PCB (X)

and

C

entails let

Γ

C^{'}

Proof: The proof is by structural induction on a derivation of

C, Γ ⊢ t : T

. In each proof case, we adopt the notations of Figure 1-8.

Case HmD-VarInst. The rule's conclusion is $C \land D, Γ ⊢ x : T$ . By hypothesis, we have $C \land D ⊩ \exists Γ$ (1) and $f p i (C, D, Γ) = \emptyset$ (2). The rule's premise is $Γ (x) = \forall \bar{x} [D] . T$ (3). By VAR, we have $x ⪯ T ⊢ x : T$ , so there remains to establish $C \land D ⊩$ let $Γ$ in $x ⪯ T$ (4). By (3), (2), and C-INID, the constraint let $Γ$ in $x ⪯ T$ is equivalent to let $Γ$ in $\forall \bar{x} [D]$ . $T ⪯ T$ , which, by (2) and C-IN*, is itself equivalent to $\exists Γ \land \forall \bar{x} [D] . T ⪯ T$ (5). By (1) and Lemma 1.3.19, $C \land D$ entails (5). We have established (4).
Case HmD-ABs. The rule's conclusion is $C, Γ ⊢ λ z . t : T \to T^{'}$ . Its premise is $C, (Γ; z : T) ⊢ t : T^{'} (1)$ . The constraints $\exists Γ$ and $\exists (Γ; z : T)$ are equivalent,
so the induction hypothesis applies to (1) and yields a constraint $C^{'}$ such that $C^{'} ⊢ t : T^{'} (2)$ and $C ⊩$ let $Γ; z : T$ in $C^{'}$ (3). Applying ABs to (2) yields let $z : T$ in $C^{'} ⊢ λ$ z.t : $T \to T^{'}$ . There remains to check that $C$ entails let $Γ$ in let $z : T$ in $C^{'}$ —but that is precisely (3).
Case HMD-App. The rule's conclusion is $C, Γ ⊢ t_{1} t_{2} : T^{'}$ . Its premises are $C, Γ ⊢ t_{1} : T \to T^{'} (1)$ and $C, Γ ⊢ t_{2} : T$ (2). Applying the induction hypothesis to (1) and (2), we obtain constraints $C_{1}^{'}$ and $C_{2}^{'}$ such that $C_{1}^{'} ⊢$ $t_{1} : T \to T^{'} (3)$ and $C_{2}^{'} ⊢ t_{2} : T (4)$ and $C ⊩$ let $Γ$ in $C_{1}^{'} (5)$ and $C ⊩$ let $Γ$ in $C_{2}^{'} (6)$ . By App, (3) and (4) imply $C_{1}^{'} \land C_{2}^{'} ⊢ t_{1} t_{2} : T^{'}$ . Furthermore, by C-InAnd, (5) and (6) yield $C ⊩$ let $Γ$ in $C_{1}^{'} \land C_{2}^{'}$ .
Case hmd-LetGen. The rule's conclusion is $C \land \exists \bar{x} . D, Γ ⊢$ let $z =$ $t_{1}$ in $t_{2} : T_{2}$ . By hypothesis, we have $C \land \exists \bar{x} . D ⊩ \exists Γ (1)$ and $f p i (C, D, Γ) =$ $\emptyset$ (2). The rule's premises are $C \land D, Γ ⊢ t_{1} : T_{1}$ (3) and $\bar{x} # f t v (C, Γ)$ (4) and $C \land \exists \bar{X} . D, Γ^{'} ⊢ t_{2} : T_{2}$ (5), where $Γ^{'}$ is $Γ; z : \forall \bar{x} [D] . T_{1}$ . Applying the induction hypothesis to (3) yields a constraint $C_{1}^{'}$ such that $C_{1}^{'} ⊢ t_{1} : T_{1}$ (6) and $C \land D ⊩$ let $Γ$ in $C_{1}^{'} (7)$ . By (1), (2), and C-IN*, we have $C \land \exists \bar{x} . D ⊩ \exists Γ^{'}$ . Thus, the induction hypothesis applies to (5) and yields a constraint $C_{2}^{'}$ such that $C_{2}^{'} ⊢ t_{2} : T_{2}$ (8) and $C \land \exists \bar{x}$ . $D ⊩$ let $Γ^{'}$ in $C_{2}^{'}$ (9). By LET, (6) and (8) imply let $z : \forall V [C_{1}^{'}] \cdot T_{1}$ in $C_{2}^{'} ⊢$ let $z = t_{1}$ in $t_{2} : T_{2}$ (10). By Lemmas 1.3 .25 and 1.5.2, (10) yields let $z : \forall \bar{x} [C_{1}^{'}] \cdot T_{1}$ in $C_{2}^{'} ⊢$ let $z = t_{1}$ in $t_{2} : T_{2}$ (11), where the universal quantification is over $\bar{X}$ only. There remains to establish that $C \land \exists \bar{x} . D$ entails let $Γ; z : \forall \bar{x} [C_{1}^{'}] . T_{1}$ in $C_{2}^{'}$ (12). By (4), (2), and CLETDup, the constraint (12) is equivalent to let $Γ; z : \forall \bar{X} [$ let $Γ$ in $C_{1}^{'}] . T_{1}$ in $C_{2}^{'}$ . By (7), this constraint is entailed by let $Γ; z : \forall \bar{x} [C \land D] . T_{1}$ in $C_{2}^{'}$ , which by (4) and C-LetAnd, is equivalent to $C \land$ let $Γ; z : \forall \bar{x} [D] . T_{1}$ in $C_{2}^{'}$ , that is, $C \land$ let $Γ^{'}$ in $C_{2}^{'}$ . By (9), this constraint is entailed by $C \land \exists \bar{x}$ . $D$ .
Case HmD-Sub. The rule's conclusion is $C, Γ ⊢ t : T^{'}$ . Its premises are $C, Γ ⊢ t : T$ (1) and $C ⊩ T \leq T^{'} (2)$ . Applying the induction hypothesis to (1) yields a constraint $C^{'}$ such that $C^{'} ⊢ t : T$ (3) and $C ⊩$ let $Γ$ in $C^{'}$ (4). By Sub, (3) implies $C^{'} \land T \leq T^{'} ⊢ t : T^{'}$ . There remains to establish $C ⊩$ let $Γ$ in $(C^{'} \land T \leq T^{'})$ , which follows from (4) and (2) by C-InAnd*.

\circ

Case HmD-Exists. The rule's conclusion is

\exists \bar{x} . C, Γ ⊢ t : T

. Its premises are

C, Γ ⊢ t : T (1)

and

\bar{x} # f t v (Γ, T) (2)

. By hypothesis, we have

\exists \bar{x} . C ⊩

\exists Γ

, which by Lemma 1.3.16 implies

C ⊩ \exists Γ

. Thus, the induction hypothesis applies to (1) and yields a constraint

C^{'}

such that

C^{'} ⊢ t : T

(3) and

C ⊩

let

Γ

C^{'}

(4). By Exists, (3) and (2) imply

\exists \bar{x} . C^{'} ⊢ t

: T. There remains to establish

\exists \bar{X} . C ⊩

let

Γ

\exists \bar{x} . C^{'}

. By congruence of entailment, (4) implies

\exists \bar{X} . C ⊩ \exists \bar{X}

.let

Γ

C^{'}

. The result follows by (2) and C-InEx.

The second theorem states that if, within

PCB (X), t

has type

T

under assumption

C

, then, within

HM (X)

t

also has type

T

, under assumptions
let

Γ

C

and

Γ

. The idea is simple: the constraint

C

represents a combined assumption about the initial judgement's free type variables and free program identifiers. In

HM (X)

, these two kinds of assumptions must be maintained separately. So, we split them into a pair of an environment

Γ

, which may be chosen arbitrarily, provided it satisfies

f p i (C) \subseteq d p i (Γ)

-that is, provided it defines all program variables of interest, and the residual constraint let

Γ

C

, which has no free program identifiers, thus represents an assumption about the new judgement's type variables only. Distinct choices of

Γ

give rise to distinct

HM (X)

judgements, which may be incomparable; this is related to the fact that ML-the-type-system does not have principal typings (Jim, 1995). Again, the hypothesis

f p i (Γ) = f p i (

let

Γ

C) = \emptyset

is natural, since we wish

Γ

and let

Γ

C

to appear in an

HM (X)

judgement.

1.5.4 Theorem: Assume

f p i (Γ) = f p i (

let

Γ

C) = \emptyset

and

C ≢

false. If

C ⊢ t : T

holds in

PCB (X)

, then let

Γ

C, Γ ⊢ t : T

holds in

HM (X)

Proof: The proof is by structural induction on a derivation of

C ⊢ t : T

. In each proof case, we adopt the notations of Figure 1-9.

By Lemma 1.3.30, the hypothesis

C ≢

false is preserved whenever the induction hypothesis is invoked. It is explicitly used only in case VAR, where it guarantees that the identifier at hand is bound in

Γ

Case VAR. The rule's conclusion is $C ⊢ x$ : T. Its premise is $C ⊩ x ⪯$ T (1). By Lemma 1.3.24, (1) and the hypothesis $C ≢$ false imply $x \in f p i (C)$ . Because let $Γ$ in $C$ has no free program identifiers, this implies $x \in d p i (Γ)$ , that is, the environment $Γ$ must define $x$ . Let $Γ (x) = \forall \bar{x} [D] \cdot T^{'}$ (2), where $\bar{X} # ftv (Γ, T)$ (3). By (2), HMD-VARInst, and HMD-SuB, we have $D \land T^{'} \leq$ $T, Γ ⊢ x : T$ . By (3) and HMD-ExisTs, this implies $\exists \bar{X} . (D \land T^{'} \leq T), Γ ⊢ x : T$ (4). Now, by (3), the constraint $\exists \bar{X} . (D \land T^{'} \leq T)$ may be written $\forall \bar{X} [D] . T^{'} ⪯ T$ (5). The hypothesis $f p i (Γ) = \emptyset$ implies $f p i (D) = \emptyset$ (6). By (6), C-InID and C ${I N}^{*}, (5)$ is equivalent to let $Γ$ in $x ⪯ T$ . Thus, (4) may be written let $Γ$ in $x ⪯$ $T, Γ ⊢ x : T$ . By (1), by congruence of entailment, and by Lemma 1.4.2, this implies let $Γ$ in $C, Γ ⊢ x : T$ .
Case ABs. The rule's conclusion is let z : $T$ in $C ⊢ λ$ z.t : $T \to T^{'}$ . Its premise is $C ⊢ t : T^{'} (1)$ . Let $Γ^{'}$ stand for $Γ; z : T$ . Applying the induction hypothesis to (1) yields let $Γ^{'}$ in $C, Γ^{'} ⊢ t : T^{'}$ . By HMD-ABS, this implies let $Γ^{'}$ in $C, Γ ⊢ λ z$ .t : $T \to T^{'}$ .
Case App. The rule's conclusion is $C_{1} \land C_{2} ⊢ t_{1} t_{2} : T^{'}$ . Its premises are $C_{1} ⊢ t_{1} : T \to T^{'}$ and $C_{2} ⊢ t_{2} : T$ . Applying the induction hypothesis yields respectively let $Γ$ in $C_{1}, Γ ⊢ t_{1} : T \to T^{'}$ and let $Γ$ in $C_{2}, Γ ⊢ t_{2} : T$ , which by Lemma 1.4.2 and HMD-APP imply let $Γ$ in $(C_{1} \land C_{2}), Γ ⊢ t_{1} t_{2} : T^{'}$ .

\circ

Case LET. The rule's conclusion is let

z : \forall V [C_{1}] \cdot T_{1}

C_{2} ⊢

let

z =

t_{1}

t_{2} : T_{2}

. Its premises are

C_{1} ⊢ t_{1} : T_{1} (1)

and

C_{2} ⊢ t_{2} : T_{2} (2)

. Let

\bar{X}

stand for

f t v (C_{1}, T_{1})

. We may require, w.l.o.g.,

\bar{X} # f t v (Γ, C_{2})

(3). By hypothesis, we have

f p i (Γ) = \emptyset (4)

. We also have

f p i (

let

Γ; z : \forall V [C_{1}] . T_{1}

C_{2}) = \emptyset

, which implies

f p i (

let

Γ

C_{1}) = \emptyset

. Thus, the induction hypothesis applies to (1) and yields let

Γ

C_{1}, Γ ⊢ t_{1} : T_{1}

(5). Now, let

σ

stand for

\forall \bar{X} [

let

Γ

C_{1}] . T_{1}

and

Γ^{'}

stand for

Γ; z : σ

. We have

f p i (Γ^{'}) =

f p i (

let

Γ^{'}

C_{2}) = \emptyset

. Thus, the induction hypothesis applies to (2) and yields let

Γ^{'}

C_{2}, Γ^{'} ⊢ t_{2} : T_{2}

(6). Let us now weaken (5) and (6) so as to make them suitable premises for HMD-LETGEN. Applying Lemma 1.4.2 to (5) yields (let

Γ^{'}

C_{2}

)

\land (

let

Γ

C_{1}

Γ ⊢ t_{1} : T_{1}

(7). Applying Lemma 1.4.2 to (6) yields (let

Γ^{'}

C_{2}

)

\neg \exists \bar{X}

. (let

Γ

C_{1}

Γ^{'} ⊢ t_{2} : T_{2}

(8). Last, (3) implies

\bar{X} # f t v (Γ

, let

Γ^{'}

C_{2}

) (9). Applying Hmd-LetGen to (7), (9) and (8), we obtain (let

Γ^{'}

C_{2}) \land \exists \bar{x}

. (let

Γ

C_{1}

Γ ⊢

let z

= t_{1}

t_{2} : T_{2}

(10). Now, by (4), (3), and C-LetDup, let

Γ^{'}

C_{2}

is equivalent to let

Γ; z : \forall \bar{X} [C_{1}] . T_{1}

C_{2}

. Using this fact, as well as (3), C-InEx, and C-InAnd, we find that the constraint (let

Γ^{'}

C_{2}

)

\neg \exists \bar{x}

. (let

Γ

C_{1}

) is equivalent to let

Γ

in (let

z

\forall \bar{X} [C_{1}] . T_{1}

C_{2} \land \exists \bar{x} . C_{1}

), which by definition of the let form, is itself equivalent to let

Γ; z : \forall \bar{X} [C_{1}] . T_{1}

C_{2}

. Last, by definition of

\bar{X}

, this constraint is let

Γ; z : \forall V [C_{1}]

T_{1}

C_{2}

. Thus, (10) is the goal.

Case Sub. The rule's conclusion is $C \land T \leq T^{'} ⊢ t : T^{'}$ . Its premise is $C ⊢ t$ : $T$ (1). Applying the induction hypothesis to (1) yields let $Γ$ in $C, Γ ⊢ t : T$ (2). By Lemma 1.4.2 and HMD-Sub, (2) implies (let $Γ$ in $C$ ) $\land T \leq T^{'}, Γ ⊢ t : T^{'}$ , which by C-InAnd* may be written let $Γ$ in $(C \land T \leq T^{'}), Γ ⊢ t : T^{'}$ .

\circ

Case ExIsTs. The rule's conclusion is

\exists \bar{x} . C ⊢ t

: T. Its premises are

C ⊢

t : T

(1) and

\bar{X} # f t v (T)

(2). We may further require, w.l.o.g.,

\bar{X} # f t v (Γ)

(3). Applying the induction hypothesis to (1) yields let

Γ

C, Γ ⊢ t : T

(4). Applying HmD-Exists to (2), (3), and (4), we find

\exists \bar{X}

.let

Γ

C, Γ ⊢ t : T

, which, by (3) and C-INEx, may be written let

Γ

\exists \bar{x} . C, Γ ⊢ t : T

As a corollary, we find that, for closed programs, the type systems

HM (X)

and

PCB (X)

coincide. In particular, a program is well-typed with respect to one if and only if it is well-typed with respect to the other. This supports the view that

PCB (X)

is an alternate formulation of

HM (X)

1.5.5 Theorem: Assume

f p i (C) = \emptyset

and

C ≢

false. Then,

C, \emptyset ⊢ t : T

holds in

H M (X)

if and only if

C ⊢ t : T

holds in

PCB (X)

1.6 Constraint generation

We now explain how to reduce type inference problems for

PCB (X)

to constraint solving problems. A type inference problem consists of an expression

\begin{aligned} [[x : T]] & = x ⪯ T \\ [[λ z \cdot t : T]] & = \exists x_{1} X_{2} \cdot (let z : x_{1} in [[t : x_{2}]] \land X_{1} \to x_{2} \leq T) \\ [[t_{1} t_{2} : T]] & = \exists x_{2} \cdot ([[t_{1} : x_{2} \to T]] \land [[t_{2} : x_{2}]]) \\ [[let z = t_{1} in t_{2} : T]] & = let z : \forall x [[[t_{1} : x]]] \cdot X in [[t_{2} : T]] \end{aligned}

Figure 1-10: Constraint generation

t

and a type

T

of kind

⋆

. The problem is to determine whether

t

is well-typed with type

T

, that is, whether there exists a satisfiable constraint

C

such that

C ⊢ t : T

holds. This formulation of the problem may seem to require an appropriate type

T

to be known in advance; this is not really the case, since

T

may be a type variable. A constraint solving problem consists of a constraint

C

. The problem is to determine whether

C

is satisfiable. To reduce a type inference problem (

t, T)

to a constraint solving problem, we must produce a constraint

C

that is both sufficient and necessary for

C ⊢ t : T

to hold. Below, we explain how to compute such a constraint, which we write

[[t : T]]

. We check that it is indeed sufficient by proving

[[t : T]] ⊢ t : T

. That is, the constraint

[[t : T]]

is specific enough to guarantee that

t

has type

T

. We say that constraint generation is sound. We check that it is indeed necessary by proving that, for every constraint

C, C ⊢ t : T

implies

C ⊩ [[t : T]]

. That is, every constraint that guarantees that

t

has type

T

is at least as specific as

[[t : T]]

. We say that constraint generation is complete. Together, these properties mean that

[[t : T]]

is the least specific constraint that guarantees that

t

has type

T

We now see how to reduce a type inference problem to a constraint solving problem. Indeed, if there exists a satisfiable constraint

C

such that

C ⊢ t : T

holds, then, by the completeness property,

C ⊩ [[t : T]]

holds, so

[[t : T]]

is satisfiable. Conversely, the soundness property states that

[[t : T]] ⊢ t : T

holds, so, if

[[t : T]]

is satisfiable, then there exists a satisfiable constraint

C

such that

C ⊢ t : T

holds. In other words,

t

is well-typed with type

T

if and only if

[[t : T]]

is satisfiable.

The existence of such a constraint is the analogue of the existence of principal type schemes in classic presentations of ML-the-type-system (Damas and Milner, 1982). Indeed, a principal type scheme is least specific in the sense that all valid types are substitution instances of it. Here, the constraint

[[t : T]]

is least specific in the sense that all valid constraints entail it. Earlier, we have established a connection between constraint entailment and refinement of type substitutions, in the specific case of equality constraints interpreted over a free algebra of finite types; see Lemma 1.3.39.

The constraint

[[t : T]]

is defined in Figure 1-10 by induction on the structure of the expression

t

. We refer to these defining equations as the constraint generation rules. The definition is quite terse. It is perhaps even simpler than the declarative specification of

PCB (X)

given in Figure 1-9; yet, we prove below that the two are equivalent.

Before explaining the definition, we state the requirements that bear on the type variables

X_{1}, X_{2}

, and

X

, which appear bound in the right-hand sides of the second, third, and fourth equations. These type variables must have kind

⋆

. They must be chosen distinct (that is,

X_{1} \neq X_{2}

in the second equation) and fresh in the following sense: type variables that appear bound in an equation's right-hand side must not appear free in the equation's left-hand side. Provided this restriction is obeyed, different choices of

X_{1}, X_{2}

, and

X

lead to

α

-equivalent constraints - that is, to the same constraint, since we identify objects up to

α

-conversion - which guarantees that the above equations make sense. We remark that, since expressions do not have free type variables, the freshness requirement may be simplified to: type variables that appear bound in an equation's right-hand side must not appear free in T. However, this simplification is rendered invalid by the introduction of type annotations within expressions (page 102). Please note that we are able to state a formal freshness requirement. This is made possible by the fact that

[[t : T]]

has no free type variables other than those of

T

, which in turn depends on our explicit use of existential quantification.

Let us now review the four equations. The first one simply mirrors VAR. The second one requires

t

to have type

x_{2}

under the hypothesis that

z

has type

X_{1}

, and forms the arrow type

X_{1} \to X_{2}

; this corresponds to ABs. Here,

X_{1}

and

X_{2}

must be fresh type variables, because we cannot in general guess the expected types of

z

and

t

. The expected type

T

is required to be a supertype of

X_{1} \to X_{2}

; this corresponds to SUB. We must bind the fresh type variables

X_{1}

and

X_{2}

, so as to guarantee that the generated constraint is unique up to

α

-conversion. Furthermore, we must bind them existentially, because we intend the constraint solver to choose some appropriate value for them. This is justified by Exists. The third equation uses the fresh type variable

X_{2}

to stand for the unknown type of

t_{2}

. The subexpression

t_{1}

is expected to have type

X_{2} \to T

. This corresponds to APP. The fourth equation, which corresponds to LET, is most interesting. It summons a fresh type variable

X

and produces

[[t_{1} : x]]

. This constraint, whose sole free type variable is

X

, is the least specific constraint that must be imposed on

X

so as to make it a valid type for

t_{1}

. As a result, the type scheme

\forall x [[[t_{1} : x]]] . X

, abbreviated

σ

in the following, is a principal type scheme for

t_{1}

. There remains to place

[[t_{2} : T]]

inside the context let

z : σ

◻

. Indeed, when placed inside this context, an instantiation constraint of the form

z ⪯ T^{'}

acquires the meaning

σ ⪯ T^{'}

, which by definition of

σ

and by Lemma 1.6.4 (see below) is equivalent to

[[t_{1} : T^{'}]]

. Thus, the constraint produced by the fourth equation simulates a textual expansion of the let construct, whereby every occurrence of

z

would be replaced with

t_{1}

. Thanks to type scheme introduction and instantiation constraints, however, this effect is achieved without duplication of source code or constraints. In other words, constraint generation has linear time and space complexity; duplication may take place during constraint solving only.

1.6.1 EXERCISE

[⋆, ↛]

: Define the size of an expression, of a type, and of a constraint, viewed as abstract syntax trees. Check that the size of

[[t : T]]

is linear in the sum of the sizes of

t

and

T

We now establish several properties of constraint generation. We begin with soundness, whose proof is straightforward.

1.6.2 Theorem [Soundness]:

t : T]] ⊢ t : T

Proof: By induction on the structure of

t

Case $x$ . The goal $x ⪯ T ⊢ x : T$ follows from VAR.
Case $λ$ z.t. By the induction hypothesis, we have $[[t : x_{2}]] ⊢ t : x_{2}$ . By ABs, this implies let $z : x_{1}$ in $[[t : x_{2}]] ⊢ λ z$ . $t : x_{1} \to X_{2}$ . By SuB, this implies let $z : X_{1}$ in $[[t : X_{2}]] \land X_{1} \to X_{2} \leq T ⊢ λ z . t : T$ . Lastly, because $X_{1} X_{2} # ftv (T)$ holds, ExISTS applies and yields $[[λ z . t : T]] ⊢ λ z . t : T$ .
Case $t_{1} t_{2}$ . By the induction hypothesis, we have $[[t_{1} : x_{2} \to T]] ⊢ t_{1}$ : $x_{2} \to T$ and $[[t_{2} : x_{2}]] ⊢ t_{2} : x_{2}$ . By APP, this implies $[[t_{1} : x_{2} \to T]] \land$ $[[t_{2} : X_{2}]] ⊢ t_{1} t_{2} : T$ . Because $X_{2} \notin f t v (T)$ holds, ExISTs applies and yields $[[t_{1} t_{2} : T]] ⊢ t_{1} t_{2} : T$ .
Case let $z = t_{1}$ in $t_{2}$ . By the induction hypothesis, we have $[[t_{1}$ : $x]] ⊢ t_{1} : x$ and $[[t_{2} : T]] ⊢ t_{2} :$ T. By LET, these imply let $z : \forall V [[[t_{1} :$ $x]]] . X$ in $[[t_{2} : T]] ⊢$ let $z = t_{1}$ in $t_{2} : T$ . Because $f t v ([[t_{1} : X]])$ is $X$ , the universal quantification on $V$ really bears on $X$ alone. We have proved $[[l$ et $z = t_{1}$ in $t_{2}$ : $T]] ⊢$ let $z = t_{1}$ in $t_{2} : T$ .

The following lemmas are used in the proof of the completeness property and in a number of other occasions. The first two state that

[[t : T]]

is covariant with respect to

T

. Roughly speaking, this means that enough subtyping constraints are generated to achieve completeness with respect to SUB.

1.6.3 Lemma:

[[t : T]] \land T \leq T^{'}

entails

[[t : T^{'}]]

1.6.4 Lemma:

X \notin f t v (T)

implies

\exists X . ([[t : X]] \land X \leq T) \equiv [[t : T]]

The next lemma gives a simplified version of the second constraint generation rule, in the specific case where the expected type is an arrow type. Then, fresh type variables need not be generated; one may directly use the arrow's domain and codomain instead.

Lemma:

[[λ

z.t :

T_{1} \to T_{2}]]

is equivalent to let

z : T_{1}

[[t : T_{2}]]

We conclude with the completeness property.

1.6.6 Theorem [Completeness]: if

C ⊢ t : T

, then

C ⊩ [[t : T]]

Proof: By induction on the derivation of

C ⊢ t : T

๑ Case VAR. The rule's conclusion is

C ⊢ x

: T. Its premise is

C ⊩ x ⪯ T

, which is also the goal.

Case ABs. The rule's conclusion is let z : $T$ in $C ⊢ λ z . t : T \to T^{'}$ . Its premise is $C ⊢ t : T^{'}$ . By the induction hypothesis, we have $C ⊩ [[t : T^{'}]]$ . By congruence of entailment, this implies let $z : T$ in $C ⊩$ let $z : T$ in $[[t : T^{'}]]$ , which, by Lemma 1.6.5, may be written let $z : T$ in $C ⊩ [[λ z . t : T \to T^{'}]]$ .
Case App. The rule's conclusion is $C_{1} \land C_{2} ⊢ t_{1} t_{2} : T^{'}$ . Its premises are $C_{1} ⊢ t_{1} : T \to T^{'}$ and $C_{2} ⊢ t_{2} : T$ . By the induction hypothesis, we have $C_{1} ⊩$ $[[t_{1} : T \to T^{'}]]$ and $C_{2} ⊩ [[t_{2} : T]]$ . Thus, $C_{1} \land C_{2}$ entails $[[t_{1} : T \to T^{'}]] \land [[t_{2} : T]]$ , which, by C-NAMEEQ, may be written $\exists X_{2} \cdot (X_{2} = T \land [[t_{1} : X_{2} \to T^{'}]] \land [[t_{2} : X_{2}]])$ , where $X_{2} \notin f t v (T, T^{'})$ . Forgetting about the equation $X_{2} = T$ , we find that $C_{1} \land C_{2}$ entails $\exists X_{2} \cdot ([[t_{1} : X_{2} \to T^{'}]] \land [[t_{2} : X_{2}]])$ , which is precisely $[[t_{1} t_{2} : T^{'}]]$ .
Case Let. The rule's conclusion is let $z : \forall V [C_{1}] . T_{1}$ in $C_{2} ⊢$ let $z =$ $t_{1}$ in $t_{2} : T_{2}$ . Its premises are $C_{1} ⊢ t_{1} : T_{1}$ and $C_{2} ⊢ t_{2} : T_{2}$ . By the induction hypothesis, we have $C_{1} ⊩ [[t_{1} : T_{1}]]$ and $C_{2} ⊩ [[t_{2} : T_{2}]]$ , which implies let $z : \forall V [C_{1}] . T_{1}$ in $C_{2} ⊩$ let $z : \forall V [[[t_{1} : T_{1}]]] . T_{1}$ in $[[t_{2} : T_{2}]]$ (1).

Now, let us establish true

⊩ \forall x [[[t_{1} : x]]] . x ⪯ \forall V [[[t_{1} : T_{1}]]] . T_{1}

(2). By definition, this requires proving

\exists {\bar{X}}_{1} \cdot ([[t_{1} : T_{1}]] \land T_{1} \leq Z) ⊩ \exists X . ([[t_{1} : x]] \land X \leq

Z) (3), where

{\bar{X}}_{1} = f t v (T_{1})

and

Z \notin X {\bar{X}}_{1}

(4). By Lemma 1.6.3, (4), and CEx*, the left-hand side of (3) entails

[[t_{1} : z]]

. By (4) and Lemma 1.6.4, the right-hand side of (3) is

[[t_{1} : z]]

. Thus, (3) holds, and so does (2).

(2)

and Lemma 1.3.22, we have let

z : \forall V [[[t_{1} : T_{1}]]] . T_{1}

[[t_{2} : T_{2}]] ⊩

let

z : \forall X [[[t_{1} : X]]] \cdot X

[[t_{2} : T_{2}]]

(5). By transitivity of entailment, (1) and (5) yield let

z : \forall V [C_{1}] . T_{1}

C_{2} ⊩ [[

let

z = t_{1}

t_{2} : T_{2}]]

Case Sub. The rule's conclusion is $C \land T \leq T^{'} ⊢ t : T^{'}$ . Its premise is $C ⊢ t : T$ . By the induction hypothesis, we have $C ⊩ [[t : T]]$ , which implies $C \land T \leq T^{'} ⊩ [[t : T]] \land T \leq T^{'}$ . By lemma 1.6.3 and by transitivity of entailment, we obtain $C \land T \leq T^{'} ⊩ [[t : T^{'}]]$ .

\circ

Case Exists. The rule's conclusion is

\exists \bar{x} . C ⊢ t

T

. Its premises are

C ⊢ t : T

and

\bar{x} # f t v (T)

(1). By the induction hypothesis, we have

C ⊩ [[t : T]]

By congruence of entailment, this implies

\exists \bar{X} . C ⊩ \exists \bar{X}

t : T]]

(2). Furthermore, (1) implies

\bar{X}

# ftv(

[[t : T]])

(3). By (3) and C-Ex*, (2) may be written

\exists \bar{x} . C ⊩ [[t : T]]

1.7 Type soundness

We are now ready to establish type soundness for our type system. The statement that we wish to prove is sometimes known as Milner's slogan: well-typed programs do not go wrong (Milner, 1978). Below, we define well-typedness in terms of our constraint generation rules, for the sake of convenience, and establish type soundness with respect to that particular definition. Theorems 1.4.7, 1.5.4, and 1.6.6 imply that type soundness also holds when well-typedness is defined with respect to the typing judgements of

D M, HM (X)

, or

P C B (X)

. We establish type soundness by following Wright and Felleisen's so-called syntactic approach (1994b). The approach consists in isolating two independent properties. Subject reduction, whose exact statement will be given below, implies that well-typedness is preserved by reduction. Progress states that no stuck configuration is well-typed. It is immediate to check that, if both properties hold, then no well-typed program can reduce to a stuck configuration. Subject reduction itself depends on a key lemma, usually known as a (term) substitution lemma. We immediately give two versions of this lemma: the former is stated in terms of

PCB (X)

judgements, while the latter is stated in terms of the constraint generation rules.

1.7.1 Lemma [Substitution]:

C ⊢ t : T

and

C_{0} ⊢ t_{0} : T_{0}

imply let

z_{0}

\forall {\bar{x}}_{0} [C_{0}] . T_{0}

C ⊢ [z_{0} \mapsto t_{0}] t : T

Proof: The proof is by structural induction on the derivation of

C ⊢ t : T

. In each proof case, we adopt the notations of Figure 1-9. We write

σ_{0}

for

\forall {\bar{x}}_{0} [C_{0}] . T_{0}

. We refer to the hypothesis

C_{0} ⊢ t_{0} : T_{0}

as (1). We assume, w.l.o.g.,

{\bar{X}}_{0} # ftv (C, T) (2)

and

z_{0} \notin f p i (σ_{0})

(3).

○ Case VAR. The rule's conclusion is

C ⊢ x : T

(4). Its premise is

C ⊩ x ⪯

T

(5). Two subcases arise.

Subcase

x

z_{0}

. Applying Sub to (1) yields

C_{0} \land T_{0} \leq T ⊢ t_{0}

: T. By (2) and ExISTS, this implies

\exists {\bar{X}}_{0} \cdot (C_{0} \land T_{0} \leq T) ⊢ t_{0} : T

(6). Furthermore, by (2) again, the constraint

\exists {\bar{X}}_{0} \cdot (C_{0} \land T_{0} \leq T)

σ_{0} ⪯ T

, which is equivalent to let

z_{0} : σ_{0}

z_{0} ⪯ T

. As a result, (6) may be written let

z_{0} : σ_{0}

x ⪯ T ⊢

[z_{0} \mapsto t_{0}] x : T (7)

Subcase

x

isn't

z_{0}

. Then,

[z_{0} \mapsto t_{0}] x

x

. Thus, VAR yields

\exists σ_{0} \land x ⪯ T ⊢

[z_{0} \mapsto t_{0}] x : T

. By C-IN*, this may be read let

z_{0} : σ_{0}

x ⪯ T ⊢ [z_{0} \mapsto t_{0}] x

T

, that is, again (7).

In either subcase, by (5), by congruence of entailment, and by Lemma 1.5.2, (7) implies let

z_{0} : σ_{0}

C ⊢ [z_{0} \mapsto t_{0}] t : T

Case ABs. The rule's conclusion is let $z : T$ in $C ⊢ λ$ z.t : $T \to T^{'}$ . Its premise is $C ⊢ t : T^{'} (8)$ . We may assume, w.l.o.g., that $z$ is distinct from $z_{0}$ and does not occur free within $t_{0}$ or $σ_{0} (9)$ . Applying the induction hypothesis to (8) yields let $z_{0} : σ_{0}$ in $C ⊢ [z_{0} \mapsto t_{0}] t : T^{'}$ , which, by ABs, implies let $z : T$ in (let $z_{0} : σ_{0}$ in $C) ⊢ λ z$ . $[z_{0} \mapsto t_{0}] t : T \to T^{'}$ . By (9) and C-LETLet, this may be written let $z_{0} : σ_{0}$ in (let $z : T$ in $C) ⊢ [z_{0} \mapsto t_{0}] (λ z . t) : T \to T^{'}$ .
Case APp. By the induction hypothesis, by APP, and by C-InAnd.
Case LET. The rule's conclusion is let $z : \forall {\bar{x}}_{1} [C_{1}] . T_{1}$ in $C_{2} ⊢$ let $z =$ $t_{1}$ in $t_{2} : T_{2}$ , where ${\bar{x}}_{1} = ftv (C_{1}, T_{1})$ . Its premises are $C_{1} ⊢ t_{1} : T_{1} (10)$ and $C_{2} ⊢ t_{2} : T_{2}$ (11). We may assume, w.l.o.g., that $z$ is distinct from $z_{0}$ and does not occur free within $t_{0}$ or $σ_{0}$ (12). We may also assume, w.l.o.g., ${\bar{x}}_{1} #$ $f t v (σ_{0})$ (13). Applying the induction hypothesis to (10) and (11) respectively yields let $z_{0} : σ_{0}$ in $C_{1} ⊢ [z_{0} \mapsto t_{0}] t_{1} : T_{1} (14)$ and let $z_{0} : σ_{0}$ in $C_{2} ⊢ [z_{0} \mapsto$ $t_{0}] t_{2} : T_{2}$ (15). Applying LET to (14) and (15) produces let $z : \forall V [$ let $z_{0} :$ $σ_{0}$ in $C_{1}] . T_{1}$ in let $z_{0} : σ_{0}$ in $C_{2} ⊢ [z_{0} \mapsto t_{0}]$ (let $z = t_{1}$ in $t_{2}) : T_{2}$ (16). Now, we have

\begin{matrix} (19) & \begin{array}{ll} let z_{0} : σ_{0}; z : \forall {\bar{X}}_{1} [C_{1}] \cdot T_{1} in C_{2} \\ \equiv & let z_{0} : σ_{0}; z : \forall {\bar{X}}_{1} [let z_{0} : σ_{0} in C_{1}] \cdot T_{1} in C_{2} \\ \equiv & let z : \forall {\bar{X}}_{1} [let z_{0} : σ_{0} in C_{1}] \cdot T_{1}; z_{0} : σ_{0} in C_{2} \\ ⊩ & let z : \forall V [let z_{0} : σ_{0} in C_{1}] \cdot T_{1}; z_{0} : σ_{0} in C_{2} \end{array} \end{matrix}

where (17) follows from (13), (3), and C-LETDup; (18) follows from (12) and C-LetLet; and (19) is by Lemma 1.3.25. Thus, applying Lemma 1.5.2 to (16) yields let

z_{0} : σ_{0}; z : \forall {\bar{x}}_{1} [C_{1}] . T_{1}

C_{2} ⊢ [z_{0} \mapsto t_{0}]

(let

z = t_{1}

t_{2}) : T_{2}

Case Sub. By the induction hypothesis, by Sub, and by C-InAnd*.
Case Exists. The rule's conclusion is $\exists \bar{x} . C ⊢ t$ : T. Its premises are $C ⊢$ $t : T$ (20) and $\bar{X} # f t v (T)$ (21). We may assume, w.l.o.g., $\bar{X} # f t v (σ_{0})$ (22). Applying the induction hypothesis to (20) yields let $z_{0} : σ_{0}$ in $C ⊢ [z_{0} \mapsto t_{0}] t$ : $T$ , which, by (21) and ExisTs, implies $\exists \bar{x}$ . let $z_{0} : σ_{0}$ in $C ⊢ [z_{0} \mapsto t_{0}] t : T$ (23). By (22) and C-InEx, (23) is let $z_{0} : σ_{0}$ in $\exists \bar{x} . C ⊢ [z_{0} \mapsto t_{0}] t : T$ .

1.7.2 Lemma: let

z : \forall \bar{X} [[[t_{2} : T_{2}]]] \cdot T_{2}

[[t_{1} : T_{1}]]

entails

[[[z \mapsto t_{2}] t_{1} : T_{1}]]

Before going on, let us give a few definitions and formulate several requirements. First, we must define an initial environment

Γ_{0}

, which assigns a type scheme to every constant. A couple of requirements must be made to ensure that

Γ_{0}

is consistent with the semantics of constants, as specified by

\overset{δ}{\to}

. Second, we must extend constraint generation and well-typedness to configurations, as opposed to programs, since reduction operates on configurations.

Last, we must formulate a restriction to tame the interaction between side effects and let-polymorphism, which is unsound if unrestricted.

1.7.3 Definition: Let

Γ_{0}

be an environment whose domain is the set of constants

Q

. We require

f t v (Γ_{0}) = \emptyset

, fpi

(Γ_{0}) = \emptyset

, and

\exists Γ_{0} \equiv

true. We refer to

Γ_{0}

as the initial typing environment.

1.7.4 Definition: Let ref be an isolated, invariant type constructor of signature

⋆ \Rightarrow ⋆

. A store type

M

is a finite mapping from memory locations to types. We write ref

M

for the environment that maps

m

ref M (m)

when

m

is in the domain of

M

. Assuming

dom (μ)

and

dom (M)

coincide, the constraint

[[μ : M]]

is defined as the conjunction of the constraints

[[μ (m) : M (m)]]

, where

m

ranges over

dom (μ)

. Under the same assumption, the constraint

[[t / μ : T / M]]

is defined as

[[t : T]] \land [[μ : M]]

. A configuration

t / μ

is well-typed if and only if there exist a type

T

and a store type

M

such that

dom (μ) = dom (M)

and the constraint let

Γ_{0};

ref

M

[[t / μ : T / M]]

is satisfiable.

The type ref

T

is the type of references (that is, memory locations) that store data of type T. It must be invariant in its parameter, reflecting the fact that references may be read and written.

A store is a complex object: it may contain values that indirectly refer to each other via memory locations. In fact, it is a representation of the graph formed by objects and pointers in memory, which may contain cycles. We rely on store types to deal with such cycles. In the definition of well-typedness, the store type

M

imposes a constraint on the contents of the store - the value

μ (m)

must have type

M (m)

-but also plays the role of a hypothesis: by placing the constraint

[[t / μ : T / M]]

within the context let ref

M

in [], we give meaning to free occurrences of memory locations within

[[t / μ : T / M]]

, and stipulate that it is valid to assume that

m

has type

M (m)

. In other words, we essentially view the store as a large, mutually recursive binding of locations to values. Since no satisfiable constraint may have a free program identifier (Lemma 1.3.31), every well-typed configuration must be closed. The context let

Γ_{0}

in [] gives meaning to occurrences of constants within

[[t / μ : T / M]]

We now define a relation between configurations that plays a key role in the statement of the subject reduction property. The point of subject reduction is to guarantee that well-typedness is preserved by reduction. However, such a simple statement is too weak to be amenable to inductive proof. Thus, for the purposes of the proof, we must be more specific. To begin, let us consider the simpler case of a pure semantics, that is, a semantics without stores. Then, we must state that if an expression

t

has type

T

under a certain constraint, then its reduct

t^{'}

has type

T

under the same constraint. In terms of generated constraints, this statement becomes: let

Γ_{0}

[[t : T]]

entails let

Γ_{0}

[[t^{'} : T]]

Let us now return to the general case, where a store is present. Then, the statement of well-typedness for a configuration

t / μ

involves a store type

M

whose domain is that of

μ

. So, the statement of well-typedness for its reduct

t^{'} / μ^{'}

must involve a store type

M^{'}

whose domain is that of

μ^{'}

-which is larger if allocation occurred. The types of existing memory locations must not change: we must request that

M

and

M^{'}

agree on

dom (M)

, that is,

M^{'}

must extend

M

. Furthermore, the types assigned to new memory locations in

dom (M^{'}) ∖ dom (M)

might involve new type variables, that is, variables that do not appear free in

M

or T. We must allow these variables to be hidden-that is, existentially quantified - otherwise the entailment assertion cannot hold. These considerations lead us to the following definition:

1.7.5 Definition:

t / μ ⊑ t^{'} / μ^{'}

holds if and only if, for every type

T

and for every store type

M

such that

dom (μ) = dom (M)

, there exist a set of type variables

\bar{Y}

and a store type

M^{'}

such that

\bar{Y} # f t v (T, M)

and

f t v (M^{'}) \subseteq \bar{Y} \cup f t v (M)

and

dom (M^{'}) = dom (μ^{'})

and

M^{'}

extends

M

and

\begin{matrix} let Γ_{0}; ref M in [[t / μ : T / M]] \\ ⊩ \exists \bar{Y} .let Γ_{0}; ref M^{'} in [[t^{'} / μ^{'} : T / M^{'}]] \end{matrix}

The relation

⊑

is intended to express a connection between a configuration and its reduct. Thus, subject reduction may be stated as:

(⟶) \subseteq (⊑)

, that is,

⊑

is indeed a conservative description of reduction.

We have introduced an initial environment

Γ_{0}

and used it in the definition of well-typedness, but we haven't yet ensured that the type schemes assigned to constants are an adequate description of their semantics. We now formulate two requirements that relate

Γ_{0}

with

\overset{δ}{\to}

. They are specializations of the subject reduction and progress properties to configurations that involve an application of a constant. They represent proof obligations that must be discharged when concrete definitions of

Q, \overset{δ}{\to}

, and

Γ_{0}

are given.

1.7.6 Definition: We require (i)

(\overset{δ}{\to}) \subseteq (⊑)

; and (ii) if the configuration

c v_{1} \dots v_{k} / μ

(where

k \geq 0

) is well-typed, then either it is reducible, or c

v_{1} \dots v_{k}

is a value.

The last point that remains to be settled before proving type soundness is the interaction between side effects and let-polymorphism. The following example illustrates the problem:

let r = ref λ z . z in let_{-} = (r := λ z \cdot (z \hat{+} \hat{1})) in! true

This expression reduces to true

\hat{+} \hat{1}

, so it must not be well-typed. Yet, if natural type schemes are assigned to ref, !, and

:=

(see Example 1.9.5), then
it is well-typed with respect to the rules given so far, because

r

receives the polymorphic type scheme

\forall X

ref (X \to X)

, which allows writing a function of type int

\to

int into

r

and reading it back with type bool

\to

bool. The problem is that let-polymorphism simulates a textual duplication of the letbound expression ref

λ z . z

, while the semantics first reduces it to a value

m

, causing a new binding

m \mapsto λ z . z

to appear in the store, then duplicates the address

m

. The new store binding is not duplicated: both copies of

m

refer to the same memory cell. For this reason, generalization is unsound in this case, and must be restricted. Many authors have attempted to come up with a sound type system that accepts all pure programs and remains flexible enough in the presence of side effects (Tofte, 1988; Leroy, 1992). These proposals are often complex, which is why they have been abandoned in favor of an extremely simple syntactic restriction, known as the value restriction (Wright, 1995).

1.7.7 Definition: A program satisfies the value restriction if and only if all subexpressions of the form let

z = t_{1}

t_{2}

are in fact of the form let

z = v_{1}

t_{2}

. In the following, we assume that either all constants have pure semantics, or all programs satisfy the value restriction.

Put slightly differently, the value restriction states that only values may be generalized. This eliminates the problem altogether, since duplicating values does not affect a program's semantics. Note that any program that does not satisfy the value restriction can be turned into one that does and has the same semantics: it suffices to change let

z = t_{1}

t_{2}

into

(λ z . t_{2}) t_{1}

when

t_{1}

is not a value. Of course, such a transformation may cause the program to become ill-typed. In other words, the value restriction causes some perfectly safe programs to be rejected. In particular, as stated above, it prevents generalizing applications of the form

c v_{1} \dots v_{k}

, where

c

is a destructor of arity

k

. This is excessive, because many destructors have pure semantics; only a few, such as ref, allocate new mutable storage. Furthermore, we use pure destructors to encode numerous language features (Section 1.9). Fortunately, it is easy to relax the restriction to allow generalizing not only values, but also a more general class of nonexpansive expressions, whose syntax guarantees that such expressions cannot allocate new mutable storage (that is, expand the domain of the store). The term nonexpansive was coined by Tofte (1988). Nonexpansive expressions may include applications of the form

c t_{1} \dots t_{k}

, where

c

is a pure destructor of arity

k

and

t_{1}, \dots, t_{k}

are nonexpansive. Experience shows that this slightly relaxed restriction is acceptable in practice. Some other improvements to the value restriction exist; see e.g. Exercise (Garrigue, 2002). Another frequent limitation of the value restriction are constructor functions, that is, functions that only build values, which are treated as ordinary functions and not as constructors, and their applications are not considered to be
values. For instance, in the expression let

f = c v

in let

z = f

w in

t

where

c

is a constructor of arity 2, the partial application

c v

bound to

f

is a constructor function (of arity 1 ), but

f w

is treated as a regular application and cannot be generalized. Technically, the effect of the (strict) value restriction is summarized by the following result.

1.7.8 Lemma: Under the value restriction, the production

E ::=

let

z = E

t

may be suppressed from the grammar of evaluation contexts (Figure 1-1) without altering the operational semantics.

We are done with definitions and requirements. We now come to the bulk of the type soundness proof.

1.7.9 THEOREM [SUBJECT REDUCTION]:

(⟶) \subseteq (⊑)

Proof: Because

⟶

and

⟶

are the smallest relations that satisfy the rules of Figure 1-2, it suffices to prove that

⊑

satisfies these rules as well. We remark that if, for every type

T, [[t : T]] ⊩ [[t^{'} : T]]

holds, then

t / μ ⊑ t^{'} / μ

holds. (Take

\bar{Y} = \emptyset

and

M^{'} = M

and use the fact that entailment is a congruence to check that the conditions of Definition 1.7.5 are met.) We make use of this fact in cases R-BETA and R-LET below.

Case R-Beta. We have

\begin{aligned} [[(λ z . t) v : T]] \\ (1) & \equiv & \exists x . ([[λ z . t : X \to T]] \land [[v : x]]) \\ (2) & \equiv & \exists x . (let z : X in [[t : T]] \land [[v : x]]) \\ (3) & \equiv & \exists x . let z : \forall \emptyset [[[v : x]]] . X in [[t : T]] \\ (4) & ⊩ & [[[z \mapsto v] t : T]] \end{aligned}

where (1) is by definition of constraint generation; (2) is by Lemma 1.6.5; (3) is by C-LetAnd; (4) is by Lemma 1.7.2 and C-Ex*.

Case R-LEt. We have

\begin{aligned} [[let z = v in t : T]] \\ (1) & = & let z : \forall x [[[v : x]]] \cdot X in [[t : T]] \\ (2) & [[[z \mapsto v] t : T]] \end{aligned}

where (1) is by definition of constraint generation and (2) is by Lemma 1.7.2.

Case R-Delta. This case is exactly requirement (i) in Definition 1.7.6.
Case R-Extend. Our hypotheses are $t / μ ⊑ t^{'} / μ^{'} (1)$ and $dom (μ^{''}) #$ $dom (μ^{'})$ (2) and range( $μ^{''}) # dom (μ^{'} ∖ μ)$ (3). Because $dom (μ)$ must be a subset of $dom (μ^{'})$ , it is also disjoint with $dom (μ^{''})$ . Our goal is $t / μ μ^{''} ⊑$ $t^{'} / μ^{'} μ^{''} (4)$ . Thus, let us introduce a type $T$ and a store type of domain
$dom (μ μ^{''})$ , or (equivalently) two store types $M$ and $M^{''}$ whose domains are respectively $dom (μ)$ and $dom (μ^{''})$ . By (1), there exist type variables $\bar{Y}$ and a store type $M^{'}$ such that $\bar{Y} # f t v (T, M)$ (5) and $f t v (M^{'}) \subseteq \bar{Y} \cup f t v (M)$ and $dom (M^{'}) = dom (μ^{'})$ and $M^{'}$ extends $M$ (6) and let $Γ_{0}$ ; ref $M$ in $[[t / μ$ : $T / M]] ⊩ \exists \bar{Y}$ .let $Γ_{0}$ ; ref $M^{'}$ in $[[t^{'} / μ^{'} : T / M^{'}]]$ . We may further require, w.l.o.g. $\bar{Y} # ftv (M^{''}) (7)$ . Let us now add the conjunct let $Γ_{0}; ref M$ in $[[μ^{''} : M^{''}]]$ to each side of this entailment assertion. On the left-hand side, by C-InAnd and by Definition 1.7.4, we obtain let $Γ_{0}$ ; ref $M$ in $[[t / μ μ^{''} : T / M M^{''}]]$ (8). On the right-hand side, by (5), (7), C-ExAnd, and C-InAnd, we obtain $\exists \bar{Y}$ .let $Γ_{0}$ in (let ref $M^{'}$ in $[[t^{'} / μ^{'} : T / M^{'}]] \land$ let ref $M$ in $[[μ^{''} : M^{''}]])$ (9). Now, recall that $M^{'}$ extends $M$ (6) and, furthermore, (3) implies $f p i ([[μ^{''}$ : $M^{''})$ # $d p i (M^{'} ∖ M)$ (10). By (10), C-InAnd*, and C-InAnd, (9) is equivalent to $\exists \bar{Y}$ .let $Γ_{0};$ ref $M^{'}$ in $([[t^{'} / μ^{'} : T / M^{'}]] \land [[μ^{''} : M^{''}]])$ , that is, $\exists \bar{Y}$ .let $Γ_{0}$ ; ref $M^{'}$ in $[[t^{'} / μ^{'} μ^{''} : T / M^{'} M^{''}]]$ (11). Thus, we have established that (8) entails (11). Let us now place this entailment assertion within the constraint context let ref $M^{''}$ in $◻$ . On the left-hand side, because $f p i (Γ_{0}, M, M^{''}) = \emptyset$ and $d p i (M^{''}) \cap d p i (Γ_{0}, M) \subseteq dom (μ^{''}) \cap (Q \cup dom (μ)) =$ $\emptyset$ , C-LetLet applies, yielding let $Γ_{0}$ ; ref $M M^{''}$ in $[[t / μ μ^{''} : T / M M^{''}]] (12)$ . On the right-hand side, by (7), C-InEx, and by analogous reasoning, we obtain $\exists \bar{Y}$ .let $Γ_{0}$ ; ref $M^{'} M^{''}$ in $[[t^{'} / μ^{'} μ^{''} : T / M^{'} M^{''}]]$ (13). Thus, (12) entails (13). Given (5), (7), given $f t v (M^{'} M^{''}) \subseteq \bar{Y} \cup f t v (M M^{''})$ , and given that $M^{'} M^{''}$ extends $M M^{''}$ , this establishes the goal (4).
Case R-Context. The hypothesis is $t / μ ⊑ t^{'} / μ^{'}$ . The goal is $E [t] / μ ⊑$ $E [t^{'}] / μ^{'}$ . Because $⟶$ relates closed configurations only, we may assume that the configuration $E [t] / μ$ is closed, so the memory locations that appear free within $E$ are members of $dom (μ)$ . Let us now reason by induction on the structure of $E$ .

Subcase

E = []

. The hypothesis and the goal coincide.

Subcase

E = E_{1} t_{1}

. The induction hypothesis is

E_{1} [t] / μ ⊑ E_{1} [t^{'}] / μ^{'}

(1). Let us introduce a type

T

and a store type

M

such that

dom (M) = dom (μ)

. Consider the constraint let

Γ_{0}; ref M

[[E [t] / μ : T / M]] (2)

. By definition of constraint generation, C-ExAnd, C-InEx, and C-InAnd, it is equivalent to

$\exists X$ .(let $Γ_{0}; ref M$ in $[[E_{1} [t] / μ : X \to T / M]] \land$ let $Γ_{0}; ref M$ in $[[t_{1} : X]]) (3)$

where

X \notin f t v (T, M)

(4). By (1), there exist type variables

\bar{Y}

and a store type

M^{'}

such that

\bar{Y} # f t v (X, T, M)

(5) and

f t v (M^{'}) \subseteq \bar{Y} \cup f t v (M)

(6) and

dom (M^{'}) = dom (μ^{'})

and

M^{'}

extends

M

and (3) entails

\exists X . (\exists \bar{Y} . let Γ_{0}; ref M^{'} in [[E_{1} [t^{'}] / μ^{'} : X \to T / M^{'}]] \land let Γ_{0}; ref M in [[t_{1} : X]]) (7)

We pointed out earlier that the memory locations that appear free in

t_{1}

are members of

dom (M)

, which implies let ref

M

[[t_{1} : x]] \equiv

let ref

M^{'}

[[t_{1}

X】 (8). By (5), C-ExAnd, (8), C-InAnd, and by definition of constraint generation, we find that (7) is equivalent to

\exists x \bar{Y} .let Γ_{0}; ref M^{'} in ([[E_{1} [t^{'}] : X \to T]] \land [[t_{1} : X]] \land [[μ^{'} : M^{'}]]) (9) .

(4), (5) and (6) imply

X \notin f t v (M^{'})

. Thus, by C-InEx and C-ExAnd, (9) may be written

\exists \bar{Y} .let Γ_{0}; ref M^{'} in (\exists x . ([[E_{1} [t^{'}] : X \to T]] \land [[t_{1} : X]]) \land [[μ^{'} : M^{'}]]),

which, by definition of constraint generation, is

\exists \bar{Y} .let Γ_{0}; ref M^{'} in [[E [t^{'}] / μ^{'} : T / M^{'}]] (10) .

Thus, we have proved that (2) entails (10). By Definition 1.7.5, this establishes

E [t] / μ ⊑ E [t^{'}] / μ^{'}

Subcase

E = v E_{1}

. Analogous to the previous subcase.

Subcase

E =

let

z = E_{1}

t_{1}

. The induction hypothesis is

E_{1} [t] / μ ⊑

E_{1} [t^{'}] / μ^{'} (1)

. This subcase is particularly interesting, because it is where let-polymorphism and side effects interact. In the previous two subcases, we relied on the fact that the

\exists \bar{Y}

quantifier, which hides the types of the memory cells created by the reduction step, commutes with the connectives

\exists

and

\land

introduced by application contexts. However, it does not in general (left)commute with the let connective (Example 1.3.28). Fortunately, under the value restriction, this subcase never arises (Lemma 1.7.8). By Definition 1.7.7, this subcase may arise only if all constants have pure semantics, which implies

μ = μ^{'} = \emptyset

. Then, we have

\begin{aligned} let Γ_{0} in [[E [t] : T]] \\ (2) & = & let Γ_{0}; z : \forall X [[[E_{1} [t] : X]]] . X in [[t_{1} : T]] \\ (3) & \equiv & let Γ_{0}; z : \forall X [let Γ_{0} in [[E_{1} [t] : x]]] . X in [[t_{1} : T]] \\ (4) & ⊩ & let Γ_{0}; z : \forall X [let Γ_{0} in [[E_{1} [t^{'}] : X]]] . X in [[t_{1} : T]] \\ (5) & \equiv & let Γ_{0} in [[E [t^{'}] : T]] \end{aligned}

where (2) is by definition of constraint generation; (3) follows from

f t v (Γ_{0}) =

f p i (Γ_{0}) = \emptyset

and C-LETDup; (4) follows from (1), specialized to the case of a pure semantics; and (5) is obtained by performing these steps in reverse.

1.7.10 Exercise [Recommended,

⋆ ⋆ ⋆

]: Try to carry out the last subcase of the above proof in the case of an impure semantics and in the absence of the value restriction. Find out why it fails. Show that it succeeds if

\bar{Y}

is assumed to be empty. Use this fact to prove that generalization is still safe when restricted to nonexpansive expressions, provided (i) evaluating a nonexpansive expression
cannot cause new memory cells to be allocated, (ii) nonexpansive expressions are stable by substitution of values for variables, and (iii) nonexpansive expressions are preserved by reduction.

Subject reduction ensures that well-typedness is preserved by reduction.

1.7.11 Lemma: Let

t / μ ⟶ t^{'} / μ^{'}

. If

t / μ

is well-typed, then so is

t^{'} / μ^{'}

Proof: Assume

t / μ ⟶ t^{'} / μ^{'}

(1) and

t / μ

is well-typed (2). By (2) and Definition 1.7.4, there exist a type

T

and a store type

M

such that

dom (μ) =

dom (M)

and the constraint let

Γ_{0}; ref M

[[t / μ : T / M]] (3)

is satisfiable. By Theorem 1.7.9 and Definition 1.7.5, (1) implies that there exist a set of type variables

\bar{Y}

and a store type

M^{'}

such that

dom (M^{'}) = dom (μ^{'}) (4)

and the constraint (3) entails

\exists \bar{Y}

.let

Γ_{0}

; ref

M^{'}

[[t^{'} / μ^{'} : T / M^{'}]]

(5). Because (3) is satisfiable, so is (5), which implies that let

Γ_{0}

; ref

M^{'}

[[t^{'} / μ^{'} : T / M^{'}]]

is satisfiable (6). By (4) and (6) and Definition 1.7.4,

t^{'} / μ^{'}

is well-typed.

Let us now establish the progress property.

1.7.12 Lemma: If

t_{1} t_{2}

is well-typed, then

t_{1} / μ

and

t_{2} / μ

are well-typed. If let

z =

t_{1}

t_{2} / μ

is well-typed, then

t_{1} / μ

is well-typed.

1.7.13 Theorem [Progress]: If

t / μ

is well-typed, then either it is reducible, or

t

is a value.

Proof: The proof is by induction on the structure of

t

Case $t = z$ . Well-typed configurations are closed: this case cannot occur.
Case $t = m$ . $t$ is a value.
Case $t = c$ . By requirement (ii) of Definition 1.7.6.

\circ

Case

t = λ

z.t

t_{1} . t

is a value.

Case $t = t_{1} t_{2}$ . By Lemma 1.7.12, $t_{1} / μ$ is well-typed. By the induction hypothesis, either it is reducible, or $t_{1}$ is a value. If the former, by $R$ -CONTEXT and because every context of the form $E t_{2}$ is an evaluation context, the configuration $t / μ$ is reducible as well. Thus, let us assume $t_{1}$ is a value. By Lemma 1.7.12, $t_{2} / μ$ is well-typed. By the induction hypothesis, either it is reducible, or $t_{2}$ is a value. If the former, by $R$ -CONTEXT and because every context of the form $t_{1} E$ - where $t_{1}$ is a value - is an evaluation context, the configuration $t / μ$ is reducible as well. Thus, let us assume $t_{2}$ is a value. Let us now reason by cases on the structure of $t_{1}$ .

Subcase

t_{1} = z

. Again, this subcase cannot occur.

Subcase

t_{1} = m

. Because

t / μ

is well-typed, a constraint of the form let

Γ_{0}

; ref

M

(\exists x . (m ⪯ X \to T \land [[t_{2} : x]]) \land [[μ : M]])

must be satisfiable. This implies that

m

is a member of

dom (M)

and that the constraint
ref

M (m) \leq X \to T

is satisfiable. Because the type constructors ref and

\to

are incompatible, this is a contradiction. So, this subcase cannot occur.

Subcase

t_{1} = λ z t_{1}^{'}

. By R-BETA,

t / μ

is reducible.

Subcase

t_{1} = {c v}_{1} \dots v_{k}

. Then,

t

is of the form

c_{1} \dots v_{k + 1}

. The result follows by requirement (ii) of Definition 1.7.6.

Case $t =$ let $z = t_{1}$ in $t_{2}$ . By Lemma 1.7.12, $t_{1} / μ$ is well-typed. By the induction hypothesis, either $t_{1} / μ$ is reducible, or $t_{1}$ is a value. If the former, by $R$ -CONTEXT and because every context of the form let $z = E$ in $t_{2}$ is an evaluation context, the configuration $t / μ$ is reducible as well. If the latter, then $t / μ$ is reducible by $R$ -LET.

We may now conclude:

1.7.14 Theorem [Type Soundness]: Well-typed source programs do not go wrong.

Proof: We say that a source program

t

is well-typed if and only if the configuration

t / \emptyset

is well-typed, that is, if and only if

\exists X

.let

Γ_{0}

[[t : x]] \equiv

true holds. By Lemma 1.7.11, all reducts of

t / \emptyset

are well-typed. By Theorem 1.7.13, none is stuck.

Let us recall that this result holds only if the requirements of Definition 1.7.6 are met. In other words, some proof obligations remain to be discharged when concrete definitions of

Q, \overset{δ}{\to}

, and

Γ_{0}

are given. This is illustrated by several examples in the next section.

1.8 Constraint solving

We have introduced a parameterized constraint language, given equivalence laws that describe the interaction between its logical connectives, and exploited them to prove theorems about type inference and type soundness, which are valid independently of the nature of primitive constraints- the socalled predicate applications. However, there would be little point in proposing a parameterized constraint solver, because much of the difficulty of designing an efficient constraint solver precisely lies in the treatment of primitive constraints and in its interaction with let-polymorphism. For this reason, in this section, we focus on constraint solving in the setting of an equality-only free tree model. Thus, the constraint solver developed here allows performing type inference for

H M (=)

(that is, for Damas and Milner's type system) and for its extension with recursive types. Of course, some of its mechanisms may be useful in other settings. Other constraint solvers used in program analysis or type inference are described e.g. in (Aiken and Wimmers, 1992; Niehren,

Müller, and Podelski, 1997; Fähndrich, 1999; Melski and Reps, 2000; Müller, Niehren, and Treinen, 2001; Pottier, 2001b; Nielson, Nielson, and Seidl, 2002; McAllester, 2002, 2003).

We begin with a rule-based presentation of a standard, efficient first-order unification algorithm. This yields a constraint solver for a subset of the constraint language, deprived of type scheme introduction and instantiation forms. On top of it, we build a full constraint solver, which corresponds to the code that accompanies this chapter.

Unification

Unification is the process of solving equations between terms. We now present a unification algorithm due to Huet (1976) as a (nondeterministic) system of constraint rewriting rules. The specification is almost the same in the case of finite and regular tree models: only one rule, which implements the occurs check, must be removed in the latter case. In other words, the algorithm works with possibly cyclic terms, and does not rely in an essential way on the occurs check. In order to accurately reflect the behavior of the actual algorithm, which relies on a union-find data structure (Tarjan, 1975), we modify the syntax of constraints by replacing equations with multi-equations. A multi-equation is an equation that involves an arbitrary number of types, as opposed to exactly two.

1.8.1 Definition: Let there be, for every kind

κ

and for every

n \geq 1

, a predicate

_{κ}^{n}

, of signature

κ^{n} \Rightarrow \cdot

, whose interpretation is (

n

-ary) equality. The predicate constraint

=_{κ}^{n} T_{1} \dots T_{n}

is written

T_{1} = \dots = T_{n}

, and called a multi-equation. We consider the constraint true as a multi-equation of length 0 . In the following, we identify multi-equations up to permutations of their members, so a multi-equation

ϵ

of kind

κ

may be viewed as a finite multiset of types of kind

κ

. We write

ϵ = ϵ^{'}

for the multi-equation obtained by concatenating

ϵ

and

ϵ^{'}

Thus, we are interested in the following subset of the constraint language:

U ::= true ∣ false | ϵ | U \land U ∣ \exists \bar{X} . U

Equations are replaced with multi-equations; no other predicates are available. Type scheme introduction and instantiation forms are absent.

1.8.2 Definition: A multi-equation is standard if and only if its variable members are distinct and it has at most one nonvariable member. A constraint

U

is standard if and only if every multi-equation inside

U

is standard and every variable that occurs (free or bound) in

U

is a member of at most one multiequation inside

U

A union-find algorithm maintains equivalence classes (that is, disjoint sets) of variables, and associates, with each class, a descriptor, which in our case is either absent or a nonvariable term. Thus, a standard constraint represents a state of the union-find algorithm. A constraint that is not standard may be viewed as a superposition of a state of the union-find algorithm, on the one hand, and of control information, on the other hand. For instance, a multi-equation of the form

ϵ = T_{1} = T_{2}

, where

T_{1}

and

T_{2}

are nonvariable terms, may be viewed, roughly speaking, as the equivalence class

ϵ = T_{1}

, together with a pending request to solve

T_{1} = T_{2}

and to update the class's descriptor accordingly. Because multi-equations encode both state and control, our specification of unification is rather high-level. It would be possible to give a lower-level description, where state (standard conjunctions of multiequations) and control (pending binary equations) are distinguished.

1.8.3 Definition: Let

U

be a conjunction of multi-equations.

Y

is dominated by

X

with respect to

U

(written:

Y ≺_{U} X

) if and only if

U

contains a conjunct of the form

X = F \vec{T} = ϵ

, where

Y \in f t v (\bar{T}) . U

is cyclic if and only if the graph of

≺_{U}

exhibits a cycle.

The specification of the unification algorithm consists of a set of constraint rewriting rules, given in Figure 1-11. Rewriting is performed modulo

α

-conversion, modulo permutations of the members of a multi-equation, modulo commutativity and associativity of conjunction, and under an arbitrary context. The specification is nondeterministic: several rule instances may be simultaneously applicable.

S-ExAnd is a directed version of C-ExAnd, whose effect is to float up all existential quantifiers. In the process, all multi-equations become part of a single conjunction, possibly causing rules whose left-hand side is a conjunction of multi-equations, namely S-FUSE and S-CYCLE, to become applicable. S-FUSE identifies two multi-equations that share a common variable

X

, and fuses them. The new multi-equation is not necessarily standard, even if the two original multi-equations were. Indeed, it may have repeated variables or contain two nonvariable terms. The purpose of the next few rules, whose lefthand side consists of a single multi-equation, is to deal with these situations. S-STUTTER eliminates redundant variables. It only deals with variables, as opposed to terms of arbitrary size, so as to have constant time cost. The comparison of nonvariable terms is implemented by S-DECOMPOSE and SClash. S-Decompose decomposes an equation between two terms whose head symbols match. It produces a conjunction of equations between their subterms, namely

\vec{X} = \vec{T}

. Only one of the two terms remains in the original multi-equation, which may thus become standard. The terms

\vec{X}

are copiedthere are two occurrences of

\vec{X}

on the right-hand side. For this reason, we

\begin{aligned} (\exists \bar{X} \cdot U_{1}) \land U_{2} \to \exists \bar{x} \cdot (U_{1} \land U_{2}) \\ if \bar{x} # ftv (U_{2}) \\ X = ϵ \land X = ϵ^{'} \to X = ϵ = ϵ^{'} \\ X = X = ϵ \to X = ϵ \\ F \vec{x} = F \vec{T} = ϵ \to \vec{x} = \vec{T} \land F \vec{x} = ϵ \\ F T_{1} \dots T_{i} \dots T_{n} = ϵ \to \exists X . (X = T_{i} \land F T_{1} \dots X \dots T_{n} = ϵ) \\ if T_{i} \notin V \land X \notin f t v (T_{1}, \dots, T_{n}, ϵ) \\ F \vec{T} = F^{'} {\vec{T}}^{'} = ϵ \to false \\ if F \neq F^{'} \\ T \to true \\ if T \notin V \\ U \land true \to U \\ U \to false \\ if the model is syntactic and U is cyclic \\ U [false] \to false \\ if U \neq [] \end{aligned}

Figure 1-11: Unification

require them to be type variables, as opposed to terms of arbitrary size. (We slightly abuse notation by using

\vec{x}

to denote a vector of type variables whose elements are not necessarily distinct.) By doing so, we allow explicitly reasoning about sharing: since a variable represents a pointer to an equivalence class, we explicitly specify that only pointers, not whole terms, are copied. As a result of this decision,

S

-DECOMPOSE is not applicable when both terms at hand have a nonvariable subterm. S-NAME- 1 remedies this problem by introducing a fresh variable that stands for one such subterm. When repeatedly applied, S-NAME-1 yields a unification problem composed of so-called small terms only - that is, where sharing has been made fully explicit. S-CLASH complements S-DECOmpose by dealing with the case where two terms with different head symbols are equated; in a free tree model, such an equation is false, so failure is signaled. S-SingLE and S-TRUE suppress multi-equations of size 1 and 0 , respectively, which are tautologies. S-SINGLE is restricted to nonvariable terms so as not to break the property that every variable is a member
of exactly one multi-equation (Definition 1.8.2). S-CYCLE is the occurs check: that is, it signals failure if the constraint is cyclic. It is applicable only in the case of syntactic unification, that is, when ground types are finite trees. It is a global check: its left-hand side is an entire conjunction of multi-equations.

S-FAIL propagates failure;

U

ranges over unification constraint contexts.

The constraint rewriting system in Figure 1-11 enjoys the following properties. First, rewriting is strongly normalizing, so the rules define a (nondeterministic) algorithm. Second, rewriting is meaning-preserving. Third, every normal form is either false or of the form

\exists \bar{X} . U

, where

U

is satisfiable. The latter two properties indicate that the algorithm is indeed a constraint solver.

1.8.4 Lemma: The rewriting system

\to

is strongly normalizing.

1.8.5 Lemma:

U_{1} \to U_{2}

implies

U_{1} \equiv U_{2}

1.8.6 Lemma: Every normal form is either false or of the form

X [U]

, where

X

is an existential constraint context,

U

is a standard conjunction of multi-equations and, if the model is syntactic,

U

is acyclic. These conditions imply that

U

is satisfiable.

A constraint solver

On top of the unification algorithm, we now define a constraint solver. Its specification is independent of the rules and strategy employed by the unification algorithm. However, the structure of the unification algorithm's normal forms, as well as the logical properties of multi-equations, are exploited when performing generalization, that is, when creating and simplifying type schemes. Like the unification algorithm, the constraint solver is specified in terms of a reduction system. However, the objects that are subject to rewriting are not just constraints: they have more complex structure. Working with such richer states allows distinguishing the solver's external language - namely, the full constraint language, which is used to express the problem that one wishes to solve - and an internal language, introduced below, which is used to describe the solver's private data structures. In the following,

C

and

D

range over external constraints, that is, constraints that were part of the solver's input. External constraints are to be viewed as abstract syntax trees, subject to no implicit laws other than

α

-conversion. As a simplifying assumption, we require external constraints not to contain any occurrence of false-otherwise the problem at hand is clearly false. Internal data structures include unification constraints

U

, as previously studied, and stacks. Stacks form a subset of constraint contexts, defined on page 24. Their syntax is as follows:

S ::= ◻ | S [[] \land C] | S [\exists \bar{x} . []] ∣ S [let x : \forall \bar{x} [[]] . T in C] ∣ S [let x : σ in []]

In the second and fourth productions,

C

is an external constraint. In the last production, we require

σ

to be of the form

\forall \bar{X} [U]

.X, and we demand

\exists σ \equiv

true. A stack may be viewed as a list of frames. Frames may be added and deleted at the inner end of a stack, that is, near the hole of the constraint context that it represents. We refer to the four kinds of frames as conjunction, existential, let, and environment frames, respectively. A state of the constraint solver is a triple

S; U; C

, where

S

is a stack,

U

is a unification constraint, and

C

is an external constraint. The state

S; U; C

is to be understood as a representation of the constraint

S [U \land C]

. The notion of

α

-equivalence between states is defined accordingly. In particular, one may rename type variables in

d t v (S)

, provided

U

and

C

are renamed as well. In short, the three components of a state play the following roles.

C

is an external constraint that the solver intends to examine next.

U

is the internal state of the underlying unification algorithm: one might think of it as the knowledge that has been obtained so far.

S

tells where the type variables that occur free in

U

and

C

are bound, associates type schemes with the program variables that occur free in

C

, and records what should be done after

C

is solved. The solver's initial state is usually of the form []; true;

C

, where

C

is the external constraint that one wishes to solve-that is, whose satisfiability one wishes to determine. For simplicity, we make the (unessential) assumption that states have no free type variables.

The solver consists of a (nondeterministic) state rewriting system, given in Figure 1-12. Rewriting is performed modulo

α

-conversion. S-UNIFY makes the unification algorithm a component of the constraint solver, and allows the current unification problem

U

to be solved at any time. Rules S-Ex-1 to SEx-4 float existential quantifiers out of the unification problem into the stack, and through the stack up to the nearest enclosing let frame, if there is any, or to the outermost level, otherwise. Their side-conditions prevent capture of type variables, and may always be satisfied by suitable

α

-conversion of the left-hand state. If

S; U; C

is a normal form with respect to the above five rules, then every type variable in

d t v (S)

is either universally quantified at a let frame, or existentially bound at the outermost level. (Recall that, by assumption, states have no free type variables.) In other words, provided these rules are applied in an eager fashion, there is no need for existential frames to appear in the machine representation of stacks. Instead, it suffices to maintain, at every let frame and at the outermost level, a list of the type variables that are bound at this point; and, conversely, to annotate every type variable in

d t v (S)

with an integer rank, which allows telling, in constant time, where the variable is bound: type variables of rank 0 are bound at the outermost level, and type variables of rank

k \geq 1

are bound at the

k^{th}

let frame down in the stack

S

. The code that accompanies this chapter adopts this convention. Ranks were

S; U; C

\to

S; U^{'}; C

U \to U^{'}

(S-UNIFY)

S; \exists \bar{x} . U; C

\to

S [\exists \bar{X} . []]; U; C

\bar{x} # ftv (C)

(S - E x - 1)

S [(\exists \bar{x} \cdot ◻) \land C]

\to

S [\exists \bar{X} . (◻ \land C)]

\bar{x} # ftv (C)

(S - E x - 2)

S [

let x :

\forall \bar{X} [\exists \bar{Y} . []] . T

C]

\to

S [

let

x : \forall \bar{X} \bar{Y} [[]] \cdot T

C]

\bar{Y} # ftv (T)

(S - E x - 3)

S [

let

x : σ

\exists \bar{x} . []]

\to

S [\exists \bar{X}

.let

x : σ

in []

]

\bar{x} # ftv (σ)

(S - E x - 4)

S; U; T_{1} = T_{2}

\to

S; U \land T_{1} = T_{2};

true

(S-SolvE-EQ)

S; U; x ⪯ T

\to

S; U; S (x) ⪯ T

(S-SoLVE-ID)

S; U; C_{1} \land C_{2}

\to

S [[] \land C_{2}]; U; C_{1}

(S-SolvE-And)

S; U; \exists \bar{X} . C

\to

S [\exists \bar{X} . []]; U; C

\bar{x} # ftv (U)

(S-SOLVE-Ex)

S; U;

let

x : \forall \bar{x} [D] . T

C

\to

S [

let

x : \forall \bar{X} [◻] . T

C]; U; D

\bar{x} # ftv (U)

(S-SOLVE-LET)

S [◻ \land C]; U;

true

\to

S; U; C

(S-POP-AND)

S [

let

x : \forall \bar{x} [[]] T

C]; U

; true

\to

S [

let

x : \forall \bar{x} X [[]] X

C]

U \land X = T;

true

x \notin ftv (U, T) \land T \notin V

(S - N A M E - 2)

S [

let

x : \forall \bar{X} Y [[]] . X

C]; Y = Z = ϵ \land U

; true

\to

S [

let

x : \forall \bar{X} Y [[]] . θ (X)

C]

Y \land Z = θ (ϵ) \land θ (U);

true

Y \neq Z \land θ = [Y \mapsto Z]

(S-COMpREss)

S [

let

x : \forall \bar{X} Y [[] . X

C]; Y = ϵ \land U

; true

\to

S [

let

x : \forall \bar{X} []] \cdot X

C]; ϵ \land U

; true

Y \notin x \cup ftv (ϵ, U)

(S-UnNAME)

S [

let

x : \forall \bar{X} \bar{Y} [[]] . X

C]; U;

true

\to

S [\exists \bar{Y}

.let

x : \forall \bar{X} [◻] . X

C]; U;

true

\bar{Y} # ftv (C) \land \exists \bar{X} . U

determines

\bar{Y}

(S-LETALL)

S [

let x :

\forall \bar{x} [[]] . x

C]; U_{1} \land U_{2};

true

\to

S [

let x :

\forall \bar{x} [U_{2}] \cdot X

◻]; U_{1}; C

\bar{x} # ftv (U_{1}) \land \exists \bar{x} \cdot U_{2} \equiv

true

(S-POP-LET)

S [

let

x : σ

in []

]; U

; true

\to

S; U;

true

(S-Pop-Env)

| $S ; U ; C$ | $\rightarrow$ | $S ; U^{\prime} ; C$ if $U \rightarrow U^{\prime}$ | (S-UNIFY) | | :---: | :---: | :---: | :---: | | $S ; \exists \overline{\mathrm{x}} . U ; C$ | $\rightarrow$ | $S[\exists \overline{\mathrm{X}} .[]] ; U ; C$ if $\overline{\mathrm{x}} \# \operatorname{ftv}(C)$ | $(\mathrm{S}-\mathrm{Ex}-1)$ | | $S[(\exists \overline{\mathrm{x}} \cdot \square) \wedge C]$ | $\rightarrow$ | $S[\exists \overline{\mathrm{X}} .(\square \wedge C)]$ if $\overline{\mathrm{x}} \# \operatorname{ftv}(C)$ | $(\mathrm{S}-\mathrm{Ex}-2)$ | | $S[$ let x : $\forall \overline{\mathrm{X}}[\exists \overline{\mathrm{Y}} .[]] . \mathrm{T}$ in $C]$ | $\rightarrow$ | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{X}} \overline{\mathrm{Y}}[[]] \cdot \mathrm{T}$ in $C]$ if $\overline{\mathrm{Y}} \# \operatorname{ftv}(\mathrm{T})$ | $(\mathrm{S}-\mathrm{Ex}-3)$ | | $S[$ let $\mathrm{x}: \sigma$ in $\exists \overline{\mathrm{x}} .[]]$ | $\rightarrow$ | $S[\exists \overline{\mathrm{X}}$.let $\mathrm{x}: \sigma$ in []$]$ if $\overline{\mathrm{x}} \# \operatorname{ftv}(\sigma)$ | $(\mathrm{S}-\mathrm{Ex}-4)$ | | $S ; U ; \mathrm{T}_{1}=\mathrm{T}_{2}$ | $\rightarrow$ | $S ; U \wedge \mathrm{T}_{1}=\mathrm{T}_{2} ;$ true | (S-SolvE-EQ) | | $S ; U ; \mathrm{x} \preceq \mathrm{T}$ | $\rightarrow$ | $S ; U ; S(\mathrm{x}) \preceq \mathrm{T}$ | (S-SoLVE-ID) | | $S ; U ; C_{1} \wedge C_{2}$ | $\rightarrow$ | $S\left[[] \wedge C_{2}\right] ; U ; C_{1}$ | (S-SolvE-And) | | $S ; U ; \exists \overline{\mathrm{X}} . C$ | $\rightarrow$ | $S[\exists \overline{\mathrm{X}} .[]] ; U ; C$ if $\overline{\mathrm{x}} \# \operatorname{ftv}(U)$ | (S-SOLVE-Ex) | | $S ; U ;$ let $\mathrm{x}: \forall \overline{\mathrm{x}}[D] . \mathrm{T}$ in $C$ | $\rightarrow$ | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{X}}[\mathrm{\square}] . \mathrm{T}$ in $C] ; U ; D$ if $\overline{\mathrm{x}} \# \operatorname{ftv}(U)$ | (S-SOLVE-LET) | | $S[\square \wedge C] ; U ;$ true | $\rightarrow$ | $S ; U ; C$ | (S-POP-AND) | | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{x}}[\mathrm{[]}] \mathrm{T}$ in $C] ; U$; true | $\rightarrow$ | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{x}} \mathrm{X}[[]] \mathrm{X}$ in $C]$ $U \wedge \mathrm{X}=\mathrm{T} ;$ true if $\mathrm{x} \notin \operatorname{ftv}(U, \mathrm{~T}) \wedge \mathrm{T} \notin \mathcal{V}$ | $(\mathrm{S}-\mathrm{NAME}-2)$ | | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{X}} \mathrm{Y}[[]] . \mathrm{X}$ in $C] ; \mathrm{Y}=\mathrm{Z}=\epsilon \wedge U$; true | $\rightarrow$ | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{X}} \mathrm{Y}[[]] . \theta(\mathrm{X})$ in $C]$ $\mathrm{Y} \wedge \mathrm{Z}=\theta(\epsilon) \wedge \theta(U) ;$ true if $\mathrm{Y} \neq \mathrm{Z} \wedge \theta=[\mathrm{Y} \mapsto \mathrm{Z}]$ | (S-COMpREss) | | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{X}} \mathrm{Y}[\mathrm{[}] . \mathrm{X}$ in $C] ; \mathrm{Y}=\epsilon \wedge U$; true | $\rightarrow$ | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{X}}[\mathrm{]}] \cdot \mathrm{X}$ in $C] ; \epsilon \wedge U$; true if $\mathrm{Y} \notin \mathrm{x} \cup \operatorname{ftv}(\epsilon, U)$ | (S-UnNAME) | | $S[$ let $\mathrm{x}: \forall \overline{\mathrm{X}} \overline{\mathrm{Y}}[[]] . \mathrm{X}$ in $C] ; U ;$ true | $\rightarrow$ | $S[\exists \overline{\mathrm{Y}}$.let $\mathrm{x}: \forall \overline{\mathrm{X}}[\square] . \mathrm{X}$ in $C] ; U ;$ true if $\overline{\mathrm{Y}} \# \operatorname{ftv}(C) \wedge \exists \overline{\mathrm{X}} . U$ determines $\overline{\mathrm{Y}}$ | (S-LETALL) | | $S[$ let x : $\forall \overline{\mathrm{x}}[[]] . \mathrm{x}$ in $C] ; U_{1} \wedge U_{2} ;$ true | $\rightarrow$ | $S\left[\right.$ let x : $\forall \overline{\mathrm{x}}\left[U_{2}\right] \cdot \mathrm{X}$ in $\left.\square\right] ; U_{1} ; C$ if $\overline{\mathrm{x}} \# \operatorname{ftv}\left(U_{1}\right) \wedge \exists \overline{\mathrm{x}} \cdot U_{2} \equiv$ true | (S-POP-LET) | | $S[$ let $\mathrm{x}: \sigma$ in []$] ; U$; true | $\rightarrow$ | $S ; U ;$ true | (S-Pop-Env) |

Figure 1-12: A constraint solver
initially described in (Rémy, 1992a), and also appear in (McAllester, 2003).

Rules S-Solve-EQ to S-SoLVE-LET encode an analysis of the structure of the third component of the current state. There is one rule for each possible case, except false, which by assumption cannot arise, and true, which is dealt with further on. S-SolvE-EQ discovers an equation and makes it available to the unification algorithm. S-SOLVE-ID discovers an instantiation constraint

x ⪯ T

and replaces it with

σ ⪯ T

, where the type scheme

σ = S (x)

is the type scheme carried by the nearest environment frame that defines

x

in the stack

S

. It is defined as follows:

\begin{aligned} S [[] \land C] (x) = S (x) \\ S [\exists \bar{x} . ◻] (x) = S (x) if \bar{x} # ftv (S (x)) \\ S [let y : \forall \bar{x} [◻] . T in C] (x) = S (x) if \bar{x} # ftv (S (x)) \\ S [let y : σ in ◻] (x) = S (x) if x \neq y \\ S [let x : σ in ◻] (x) = σ \end{aligned}

x \in d p i (S)

does not hold, then

S (x)

is undefined and the rule is not applicable. If it does hold, then the rule may always be made applicable by suitable

α

-conversion of the left-hand state. Please recall that, if

σ

is of the form

\forall \bar{X} [U] . X

, where

\bar{X} # ftv (T)

, then

σ ⪯ T

stands for

\exists \bar{X} . (U \land X = T)

. The process of constructing this constraint is informally referred to as "taking an instance of

σ

". It involves taking fresh copies of the type variables

\bar{X}

, of the unification constraint

U

, and of the body

X

. In the worst case, this process is just as inefficient as textually expanding the corresponding let construct in the program's source code, and leads to exponential time complexity (Mairson, Kanellakis, and Mitchell, 1991). In practice, however, the unification constraint

U

is often compact, because it was simplified before the environment frame let

x : σ

in [] was created. which is why the solver usually performs well. (The creation of environment frames, performed by S-POP-LET, is discussed below.) S-SOLVEAND discovers a conjunction. It arbitrarily chooses to explore the left branch first, and pushes a conjunction frame onto the stack, so as to record that the right branch should be explored afterwards. S-SOLVE-Ex discovers an existential quantifier and enters it, creating a new existential frame to record its existence. Similarly, S-SOLVE-LET discovers a let form and enters its left-hand side, creating a new let frame to record its existence. The choice of examining the left-hand side first is not arbitrary. Indeed, examining the right-hand side first would require creating an environment frame-but environment frames must contain simplified type schemes of the form

\forall \bar{X} [U] . X

, whereas the type scheme

\forall \bar{X} [D] . T

is arbitrary. In other words, our strategy is to simplify type schemes prior to allowing them to be copied by S-SOLVE-ID, so as to avoid any duplication of effort. The side-conditions of S-SOLVE-Ex and S-SOLVE-LET may always be satisfied by suitable

α

-conversion of the left-hand state.

Rules S-Solve-EQ to S-Solve-LEt may be referred to as forward rules, because they "move down into" the external constraint, causing the stack to grow. This process stops when the external constraint at hand becomes true. Then, part of the work has been finished, and the solver must examine the stack in order to determine what to do next. This task is performed by the last series of rules, which may be referred to as backward rules, because they "move back out", causing the stack to shrink, and possibly scheduling new external constraints for examination. These rules encode an analysis of the structure of the innermost stack frame. There are three cases, corresponding to conjunction, let, and environment frames. The case of existential stack frames need not be considered, because rules S-Ex-2 to S-Ex-4 allow either fusing them with let frames or floating them up to the outermost level, where they shall remain inert. S-POP-And deals with conjunction frames. The frame is popped, and the external constraint that it carries is scheduled for examination. S-Pop-Env deals with environment frames. Because the right-hand side of the let construct at hand has been solved - that is, turned into a unification constraint

U

-it cannot contain an occurrence of

x

. Furthermore, by assumption,

\exists σ

is true. Thus, this environment frame is no longer useful: it is destroyed. The remaining rules deal with let frames. Roughly speaking, their purpose is to change the state

S [

let

x : \forall \bar{x} [[]] . T

C]; U

; true into

S [

let

x : \forall \bar{x} [U] . T

in []

]

; true;

C

, that is, to turn the current unification constraint

U

into a type scheme, turn the let frame into an environment frame, and schedule the right-hand side of the let construct (that is, the external constraint

C

) for examination. In fact, the process is more complex, because the type scheme

\forall \bar{X} [U]

.T must be simplified before becoming part of an environment frame. The simplification process is described by rules S-NAME-2 to S-Pop-LET. In the following, we refer to type variables in

\bar{X}

as young and to type variables in

d t v (S) ∖ \bar{X}

as old. The former are the universal quantifiers of the type scheme that is being created; the latter are its free type variables.

S-NAME-2 ensures that the body

T

of the type scheme that is being created is a type variable, as opposed to an arbitrary term. If it isn't, then it is replaced with a fresh variable

X

, and the equation

X = T

is added so as to recall that

X

stands for

T

. Thus, the rule moves the term

T

into the current unification problem, where it potentially becomes subject to S-NAME-1. This ensures that sharing is made explicit everywhere. S-COMPRESS determines that the (young) type variable

Y

is an alias for the type variable

Z

. Then, every free occurrence of Y other than its defining occurrence is replaced with Z. In an actual implementation, this occurs transparently when the union-find algorithm performs path compression (Tarjan, 1975, 1979), provided we are careful never to create a link from a variable to a variable of higher rank. This requires making the unification algorithm aware of ranks, but is otherwise
easily achieved. S-UNNAME determines that the (young) type variable Y has no occurrences other than its defining occurrence in the current type scheme. (This occurs, in particular, when S-Compress has just been applied.) Then,

Y

is suppressed altogether. In the particular case where the remaining multiequation

ϵ

has cardinal 1, it may then be suppressed by S-SingLE. In other words, the combination of S-UNNAME and S-SINGLE is able to suppress young unused type variables as well as the term that they stand for. This may, in turn, cause new type variables to become eligible for elimination by

S

UNNAME. In fact, assuming the current unification constraint is acyclic, an inductive argument shows that every young type variable may be suppressed unless it is dominated either by

X

or by an old type variable. (In the setting of a regular tree model, it is possible to extend the rule so that young cycles that are not dominated either by

X

or by an old type variable are suppressed as well.) S-LETALL is a directed version of C-LETALL. It turns the young type variables

\bar{Y}

into old variables. How to tell whether

\exists \bar{X} . U

determines

\bar{Y}

is discussed later (see Lemma 1.8.7). Why S-LETALL is an interesting and important rule will be explained shortly. S-POP-LET is meant to be applied when the current state has become a normal form with respect to S-UNIFY, SName-2, S-Compress, S-UnName, and S-LetAll, that is, when the type scheme that is about to be created is fully simplified. It splits the current unification constraint into two components

U_{1}

and

U_{2}

, where

U_{1}

is made up entirely of old variables - as expressed by the side-condition

\bar{X} # ftv (U_{1})

and

U_{2}

constrains young variables only-as expressed by the side-condition

\exists \bar{X} \cdot U_{2} \equiv

true. Please note that

U_{2}

may still contain free occurrences of old type variables, so the type scheme

\forall \bar{X} [U_{2}]

X

that appears on the right-hand side is not necessarily closed. It is not obvious why such a decomposition must exist; the proof of Lemma 1.8.11 sheds more light on this issue. Let us say, for now, that S-LETALL plays a role in guaranteeing its existence, whence part of its importance. Once the decomposition

U_{1} \land U_{2}

is obtained, the behavior of

S

POP-LET is simple. The unification constraint

U_{1}

concerns old variables only, that is, variables that are not quantified in the current let frame; thus, it need not become part of the new type scheme, and may instead remain part of the current unification constraint. This is justified by C-LETAnd and C-InAnd* (see the proof of Lemma 1.8.10) and corresponds to the difference between HMX-GEN' and HMX-GEN discussed in Section 1.4. The unification constraint

U_{2}

, on the other hand, becomes part of the newly built type scheme

\forall \bar{X} [U_{2}]

.X. The property

\exists \bar{X} . U_{2} \equiv

true guarantees that the newly created environment frame meets the requirements imposed on such frames. Please note that, the more type variables are considered old, the larger

U_{1}

may become, and the smaller

U_{2}

. This is another reason why S-LETALL is interesting: by allowing more variables to be considered old, it decreases the size of the type scheme

\forall \bar{X} [U_{2}] . X

, making it cheaper to take instances of.

To complete our description of the constraint solver, there remains to explain how to decide when

\exists \bar{X} . U

determines

\bar{Y}

, since this predicate occurs in the side-condition of S-LETALL. The following lemma describes two important situations where, by examining the structure of an equation, it is possible to discover that a constraint

C

determines some of its free type variables

\bar{Y}

(Definition 1.3.26). In the first situation, the type variables

\bar{Y}

are equated with or dominated by a distinct type variable X that occurs free in

C

. In that case, because the model is a free tree model, the values of the type variables

\bar{Y}

are determined by the value of

X

- they are subtrees of it at specific positions. For instance,

X = Y_{1} \to Y_{2}

determines

Y_{1} Y_{2}

, while

\exists Y_{1} . (X = Y_{1} \to Y_{2})

determines

Y_{2}

. In the second situation, the type variables

\bar{Y}

are equated with a term T, all of whose free type variables are free in

C

. Again, the value of the type variables

\bar{Y}

is then determined by the values of the type variables

f t v (T)

-indeed, the term

T

itself defines a function that maps the latter to the former. For instance,

X = Y_{1} \to Y_{2}

determines

X

, while

\exists Y_{1}

(X = Y_{1} \to Y_{2})

does not. In the second situation, no assumption is in fact made about the model. Please note that

X = Y_{1} \to Y_{2}

determines

Y_{1} Y_{2}

and determines

X

, but does not simultaneously determine

{X Y}_{1} Y_{2}

1.8.7 Lemma: Let

\bar{X} # \bar{Y}

. Assume either

ϵ

X = ϵ^{'}

, where

X \notin \bar{X} \bar{Y}

and

\bar{Y} \subseteq f t v (ϵ^{'})

, or

ϵ

\bar{Y} = T = ϵ^{'}

, where

ftv (T) # \bar{X} \bar{Y}

. Then,

\exists \bar{X}

(C \land ϵ)

determines

\bar{Y}

Proof: Let

\bar{X} # \bar{Y}

(1). Let

ϕ ⊢ def Γ

\exists \bar{X}

(C \land ϵ)

(2) and

ϕ^{'} ⊢

def

Γ

\exists \bar{X}

(C \land ϵ) (3)

, where

ϕ

and

ϕ^{'}

coincide outside of

\bar{Y}

. We may assume, w.l.o.g.,

\bar{x} # f t v (Γ)

(4). By (2), (4), CM-Exists, and CM-And, we obtain

ϕ_{1} ⊢ def Γ

ϵ (5)

, where

ϕ

and

ϕ_{1}

coincide outside

\bar{x}

. By CM-Predicate, (5) implies that all members of

ϵ

have the same image through

ϕ_{1}

. Similarly, exploiting (3) and (4), we find that all members of

ϵ

have the same image through

ϕ_{1}^{'}

, where

ϕ^{'}

and

ϕ_{1}^{'}

coincide outside

\bar{X}

. Now, we claim that

ϕ_{1}

and

ϕ_{1}^{'}

coincide on

\bar{Y}

. Once the claim is established, by (1), there follows that

ϕ

and

ϕ^{'}

must coincide on

\bar{Y}

as well, which is the goal. So, there only remains to establish the claim; we distinguish two subcases.

Subcase

ϵ

X = ϵ^{'}

and

X \notin \bar{X} \bar{Y} (6)

and

\bar{Y} \subseteq f t v (ϵ^{'})

(7). Because

ϕ_{1}

and

ϕ_{1}^{'}

coincide outside

\bar{X} \bar{Y}

and by (6), we have

ϕ_{1} (X) = ϕ_{1}^{'} (X)

. As a result, all members of

ϵ^{'}

have the same image through

ϕ_{1}

and

ϕ_{1}^{'}

. In a free tree model, where decomposition is valid, a simple inductive argument shows that

ϕ_{1}

and

ϕ_{1}^{'}

must coincide on

f t v (ϵ^{'})

, hence - by (7) - also on

\bar{Y}

Subcase

ϵ

\bar{Y} = T = ϵ^{'}

and

f t v (T) # \bar{X} \bar{Y} (8)

. Because

ϕ_{1}

and

ϕ_{1}^{'}

coincide outside

\bar{X} \bar{Y}

and by (8), we have

ϕ_{1} (T) = ϕ_{1}^{'} (T)

. Thus, for every

Y \in \bar{Y}

, we have

ϕ_{1} (Y) = ϕ_{1} (T) = ϕ_{1}^{'} (T) = ϕ_{1}^{'} (Y)

. That is,

ϕ_{1}

and

ϕ_{1}^{'}

coincide on

\bar{Y}

Thanks to Lemma 1.8.7, a straightforward implementation of S-LETALL
comes to mind. The problem is, given a constraint

\exists \bar{X} . U

, where

U

is a standard conjunction of multi-equations, to determine the greatest subset

\bar{Y}

\bar{X}

such that

\exists (\bar{X} ∖ \bar{Y}) . U

determines

\bar{Y}

. By the first part of the lemma, it is safe for

\bar{Y}

to include all members of

\bar{X}

that are directly or indirectly dominated (with respect to

U

) by some free variable of

\exists \bar{x} . U

. Those can be found, in time linear in the size of

U

, by a top-down traversal of the graph of

≺_{U}

. By the second part of the lemma, it is safe to close

\bar{Y}

under the closure law

X \in

\bar{X} \land (\forall Y Y ≺_{U} X \Rightarrow Y \in \bar{Y}) \Rightarrow X \in \bar{Y}

. That is, it is safe to also include all members of

\bar{X}

whose descendants (with respect to

U

) have already been found to be members of

\bar{Y}

. This closure computation may be performed, again in linear time, by a bottom-up traversal of the graph of

≺_{U}

. When

U

is acyclic, it is possible to show that this procedure is complete, that is, does compute the greatest subset

\bar{Y}

that meets our requirement. This is the topic of the following exercise.

1.8.8 EXERcise

[⋆ ⋆ ⋆, ↛]

: Assuming

U

is acyclic, prove that the above procedure computes the greatest subset

\bar{Y}

\bar{X}

such that

\exists (\bar{X} ∖ \bar{Y}) \cdot U

determines

\bar{Y}

. In the setting of a regular tree model, exhibit a satisfiable constraint

U

such that the above procedure is incomplete. Can you define a complete procedure in that setting?

The above discussion has shown that when

Y

and

Z

are equated, if

Y

is young and

Z

is old, then

S

-LetAlL allows making

Y

old as well. If binding information is encoded in terms of integer ranks, as suggested earlier, then this remark may be formulated as follows: when

Y

and

Z

are equated, if the rank of

Y

exceeds that of

Z

, then it may be decreased so that both ranks match. As a result, it is possible to attach ranks with multi-equations, rather than with variables. When two multi-equations are fused, the smaller rank is kept.

S-SOLVE-LET and S-NAME-2 to S-POP-LET are unnecessarily complex when

x

is assigned a monotype

T

, rather than an arbitrary type scheme

\forall \bar{X} [D]

.T. In that case, the combined effect of these rules may be obtained directly via the following two new rules, which may be implemented in a more efficient way:

\begin{aligned} S; U; let x : T in C \to & S [\exists x . []]; U \land x = T; let x : x in C \\ if x \notin f t v (U, T, C) \land T \notin V \\ S; U; let x : x in C \to & S [let x : x in []]; U; C (S-Solve-LET-Mono) \end{aligned}

T

isn't a variable, it is replaced with a fresh variable

X

, together with the equation

X = T

. This corresponds to the effect of S-NAME-2. Then, we directly
create an environment frame for

x

, without bothering to create and discard a let frame, since there is no way the type scheme X may be further simplified.

Let us now state and establish the properties of the constraint solver. First, the reduction system is terminating, so it defines an algorithm.

1.8.9 Lemma: The reduction system

\to

is strongly normalizing.

Second, every rewriting step preserves the meaning of the constraint that the current state represents. We recall that the state

S; U; C

is meant to represent the constraint

S [U \land C]

1.8.10 Lemma:

S; U; C \to S^{'}; U^{'}; C^{'}

implies

S [U \land C] \equiv S^{'} [U^{'} \land C^{'}]

Proof: By examination of every rule.

Case S-Unify. By Lemma 1.8.5.
Case S-Ex-1, S-Ex-2, S-Solve-Ex. By C-ExAnd.
Case S-Ex-3. By C-LETEx.
Case S-Ex-4. By C-InEx.
Case S-Solve-Eq, S-Pop-And. By C-Dup.
Case S-Solve-ID. Because $σ$ is of the form $\forall \bar{x} [U] . X$ , we have $f p i (σ) = \emptyset$ . The result follows by C-INID.
Case S-Solve-And. By C-AndAnd.
Case S-Solve-Let. By C-LetAnd.
Case S-NAme-2. By Definition 1.3.21 and C-NAmeEq, $X \notin f t v (U, T) i m -$ plies true $⊩ \forall \bar{X} [U] . T \equiv \forall \bar{X} X [U \land X = T] . X$ . The result follows by Lemma 1.3.22.
Case S-Compress. Let $θ = [Y \mapsto Z]$ . By Definition 1.3.21 and CNAMEEQ, $Y \neq Z$ implies true $⊩ \forall \bar{X} [Y = Z = ϵ \land U] . X \equiv \forall \bar{X} Y [Y \land Z =$ $θ (ϵ) \land θ (U)] . θ (X)$ . The result follows by Lemma 1.3.22.
Case S-UnName. Using Lemma 1.3.18, it is straightforward to check that $Y \notin f t v (ϵ)$ implies $\exists Y$ . $(Y = ϵ) \equiv ϵ$ . The result follows by C-ExAnD and C-LETEx.
Case S-LetAll. By C-LetAll.
Case S-Pop-Let. By C-LetAnd and C-InAnd*.
Case S-Pop-Env. By C-IN*, recalling that $\exists σ$ must be true.

Last, we classify the normal forms of the reduction system:

1.8.11 Lemma: A normal form for the reduction system

\to

is one of (i)

S; U; x ⪯ T

, where

x \notin d p i (S)

; (ii)

S

; false; true; or (iii)

X

;

U

; true, where

X

is an existential constraint context and

U

a satisfiable conjunction of multi-equations.

Proof: Because, by definition,

S; U

; false is not a valid state, a normal form for S-Solve-Eq, S-Solve-Id, S-Solve-And, S-Solve-Ex, and S-SolveLET must be either an instance of the left-hand side of S-SOLVE-ID, with

x \notin d p i (S)

, which corresponds to case (i), or of the form

S

;

U

; true. Let us consider the latter case. Because

S; U

; true is a normal form with respect to S-UNIFY, by Lemma 1.8.6,

U

must be either false of the form

X [U^{'}]

, where

U^{'}

is a standard conjunction of multi-equations and, if the model is syntactic,

U^{'}

is acyclic. The former case corresponds to (ii); thus, let us consider the latter case. Because

S; X [U^{'}]

; true is a normal form with respect to

S

-EX1 , the context

X

must in fact be empty, and

U^{'}

U

. If

S

is an existential constraint context, then we are in situation (iii). Otherwise, because

S; U

; true is a normal form with respect to S-Ex-2, S-Ex-3, and S-Ex-4, the stack

S

does not end with an existential frame. Because

S; U

; true is a normal form with respect to S-Pop-And and S-Pop-Env,

S

must then be of the form

S^{'} [

let

x : \forall \bar{X} [[I] T

C]

. Because

S; U

; true is a normal form with respect to S-NAME-2, T must be a type variable

X

. Let us write

U

U_{1} \land U_{2}

, where

\bar{X} # ftv (U_{1})

, and where

U_{1}

is maximal for this criterion. Then, consider a multi-equation

ϵ \in U

. By the first part of Lemma 1.8.7, if one variable member of

ϵ

is free (that is, outside

\bar{X}

), then

\exists \bar{X} . U

determines all other variables in

f t v (ϵ)

. Because

S; U

; true is a normal form with respect to S-LETALL, all variables in

f t v (ϵ)

must then be free (that is, outside

\bar{X}

). By definition of

U_{1}

, this implies

ϵ \in U_{1}

. By contraposition, for every multi-equation

ϵ \in U_{2}

, all variable members of

ϵ

are in

\bar{X}

. Furthermore, let us recall that

U_{2}

is a standard conjunction of multi-equations and, if the model is syntactic,

U_{2}

is acyclic. We let the reader check that this implies

\exists \bar{x} . U_{2} \equiv

true; the proof is a slight generalization of the last part of that of Lemma 1.8.6. Then,

S; U

; true is reducible via S-PoP-LET. This is a contradiction, so this last case cannot arise.

In case (i), the constraint

S [U \land C]

has a free program identifier x, so it is not satisfiable. In other words, the source program contains an unbound program identifier. Such an error could of course be detected prior to constraint solving, if desired. In case (ii), the unification algorithm failed. By Lemma 1.3.30, the constraint

S [U \land C]

is then false. In case (iii), the constraint

S [U \land C]

is equivalent to

X [U]

, where

U

is satisfiable, so it is satisfiable as well. Thus, each of the three classes of normal forms may be immediately identified as denoting success or failure. Thus, Lemmas 1.8.10 and 1.8.11 indeed prove that the algorithm is a constraint solver.

1.9 From ML-the-calculus to ML-the-programming-language

In this section, we explain how to extend the framework developed so far to accommodate operations on values of base type (such as integers), pairs, sums, references, and recursive function definitions. Then, we describe more complex extensions, namely algebraic data type definitions, pattern matching, and type annotations. Last, the issues associated with recursive types are briefly discussed. Exceptions are not discussed; the reader is referred to (TAPL Chapter 14).

Simple extensions

Many features of ML-the-programming-language may be introduced into MLthe-calculus by introducing new constants and extending

\overset{δ}{\to}

and

Γ_{0}

appropriately. In each case, it is necessary to check that the requirements of Definition 1.7 .6 are met, that is, the new initial environment faithfully reflects the nature of the new constants as well as the behavior of the new reduction rules. Below, we describe several such extensions in isolation.

1.9.1 Exercise [Integers, Recommended,

⋆ ⋆

]: Integer literals and integer addition have been introduced and given an operational semantics in Examples 1.2.1, 1.2.2 and 1.2.4. Let us now introduce an isolated type constructor int of signature

⋆

and extend the initial environment

Γ_{0}

with the bindings

\hat{n}

: int, for every integer

n

, and

\hat{+} :

int

\to

int

\to

int. Check that these definitions meet the requirements of Definition 1.7.6.

1.9.2 Exercise [Booleans, Recommended,

⋆ ⋆, ↛

]: Booleans and conditionals have been introduced and given an operational semantics in Exercise 1.2.6. Introduce an isolated type constructor bool to represent Boolean values and explain how to extend the initial environment. Check that your definitions meet the requirements of Definition 1.7.6. What is the constraint generation rule for the syntactic sugar if

t_{0}

then

t_{1}

else

t_{2}

1.9.3 ExERcISE [PaIrs,

⋆ ⋆, ↛]

: Pairs and pair projections have been introduced and given an operational semantics in Examples 1.2.3 and 1.2.5. Let us now introduce an isolated type constructor

\times

of signature

⋆ \otimes ⋆ \Rightarrow ⋆

, covariant in both of its parameters, and extend the initial environment

Γ_{0}

with the following bindings:

\begin{aligned} (\cdot, \cdot) : & \forall X Y . X \to Y \to X \times Y \\ π_{1} : & \forall X Y . X \times Y \to X \\ π_{2} : & \forall X Y . X \times Y \to Y \end{aligned}

Check that these definitions meet the requirements of Definition 1.7.6.

1.9.4 ExERcise [Sums,

⋆ ⋆, ↛

]: Sums have been introduced and given an operational semantics in Example 1.2.7. Let us now introduce an isolated type constructor + of signature

⋆ \otimes ⋆ \Rightarrow ⋆

, covariant in both of its parameters, and extend the initial environment

Γ_{0}

with the following bindings:

\begin{aligned} {inj}_{1} : & \forall X Y . X \to X + Y \\ {i n j}_{2} : & \forall X Y . Y \to X + Y \\ case : & \forall X Y Z . (X + Y) \to (X \to Z) \to (Y \to Z) \to Z \end{aligned}

Check that these definitions meet the requirements of Definition 1.7.6.

1.9.5 EXERcise [REfEREnces,

⋆ ⋆ ⋆

]: References have been introduced and given an operational semantics in Example 1.2.9. The type constructor ref has been introduced in Definition 1.7.4. Let us now extend the initial environment

Γ_{0}

with the following bindings:

\begin{aligned} ref : & \forall X . X \to ref X \\ ! : & \forall X . ref X \to X \\ :=: & \forall X . ref X \to X \to X \end{aligned}

Check that these definitions meet the requirements of Definition 1.7.6.

1.9.6 Exercise [Recursion, Recommended,

⋆ ⋆ ⋆

]: The fixpoint combinator fix has been introduced and given an operational semantics in Example 1.2.10. Let us now extend the initial environment

Γ_{0}

with the following binding:

fix : \forall X Y . ((X \to Y) \to (X \to Y)) \to X \to Y

Check that these definitions meet the requirements of Definition 1.7.6. Recall how the letrec syntactic sugar was defined in Example 1.2.10, and check that this gives rise to the following constraint generation rule:

\begin{aligned} let Γ_{0} in [[letrec f = λ z . t_{1} in t_{2} : T]] \\ \equiv & let Γ_{0} in let f : \forall X Y [let f : X \to Y; z : X in [[t_{1} : Y]]] X \to Y in [[t_{2} : T]] \end{aligned}

Note the somewhat peculiar structure of this constraint: the program variable

f

is bound twice in it, with different type schemes. The constraint requires all occurrences of

f

within

t_{1}

to be assigned the monomorphic type

X \to Y

. This type is generalized and turned into a type scheme before inspecting

t_{2}

, however, so every occurrence of

f

within

t_{2}

may receive a different type, as usual with let-polymorphism. A more powerful way of typechecking recursive function definitions is discussed in Section 1.10 (page 113).

Algebraic data types

Exercises 1.9.3 and 1.9.4 have shown how to extend the language with binary, anonymous products and sums. These constructs are quite general, but still have several shortcomings. First, they are only binary, while we would like to have

k

-ary products and sums, for arbitrary

k \geq 0

. Such a generalization is of course straightforward. Second, more interestingly, their components must be referred to by numeric index (as in "please extract the second component of the pair"), rather than by name ("extract the component named y"). In practice, it is crucial to use names, because they make programs more readable and more robust in the face of changes. One could introduce a mechanism that allows defining names as syntactic sugar for numeric indices. That would help a little, but not much, because these names would not appear in types, which would still be made of anonymous products and sums. Third, in the absence of recursive types, products and sums do not have sufficient expressiveness to allow defining unbounded data structures, such as lists. Indeed, it is easy to see that every value whose type

T

is composed of base types (int, bool, etc.), products, and sums must have bounded size, where the bound

| T |

is a function of T. More precisely, up to a constant factor, we have

∣

int

| = |

bool

∣ = 1

| T_{1} \times T_{2} | = 1 + | T_{1} | + | T_{2} |

, and

| T_{1} + T_{2} | = 1 + max (| T_{1} |, | T_{2} |)

. The following example describes another facet of the same problem.

1.9.7 Example: A list is either empty, or a pair of an element and another list. So, it seems natural to try and encode the type of lists as a sum of some arbitrary type (say, unit), on the one hand, and of a product of some element type and of the type of lists itself, on the other hand. With this encoding in mind, we can go ahead and write code - for instance, a function that computes the length of a list:

letrec length = λ l.case 1 (λ_{-} . \hat{0}) (λ z . \hat{1} \hat{+} length (π_{2} z))

We have used integers, pairs, sums, and the letrec construct introduced in the previous section. The code analyzes the list 1 using a case construct. If the left branch is taken, the list is empty, so 0 is returned. If the right branch is taken, then

z

becomes bound to a pair of some element and the tail of the list. The latter is obtained using the projection operator

π_{2}

. Its length is computed using a recursive call to length and incremented by 1 . This code makes perfect sense. However, applying the constraint generation and constraint solving algorithms eventually leads to an equation of the form

X = Y + (Z \times X)

, where

X

stands for the type of 1 . This equation accurately reflects our encoding of the type of lists. However, in a syntactic model, it has no solution, so our definition of length is ill-typed. It is possible to adopt a free
regular tree model,thus introducing equirecursive types into the system (TAPL Chapter 20); however, there are good reasons not to do so (page 106).

To work around this problem, ML-the-programming-language offers algebraic data type definitions, whose elegance lies in the fact that, while representing only a modest theoretical extension, they do solve the three problems mentioned above. An algebraic data type may be viewed as an abstract type that is declared to be isomorphic to a (

k

-ary) product or sum type with named components. The type of each component is declared as well, and may refer to the algebraic data type that is being defined: thus, algebraic data types are isorecursive (TAPL Chapter 20). In order to allow sufficient flexibility when declaring the type of each component, algebraic data type definitions may be parameterized by a number of type variables. Last, in order to allow the description of complex data structures, it is necessary to allow several algebraic data types to be defined at once; the definitions may then be mutually recursive. In fact, in order to simplify this formal presentation, we assume that all algebraic data types are defined at once at the beginning of the program. This decision is of course at odds with modular programming, but will not otherwise be a problem.

In the following, D ranges over a set of data types. We assume that data types form a subset of type constructors. We require each of them to be isolated and to have a signature of the form

\vec{κ} \Rightarrow ⋆

. Furthermore,

ℓ

ranges over a set

L

of labels, which we use indifferently as data constructors and as record labels. An algebraic data type definition is either a variant type definition or a record type definition, whose respective forms are

D \vec{X} \approx \sum_{i = 1}^{k} ℓ_{i} : T_{i} and D \vec{X} \approx \prod_{i = 1}^{k} ℓ_{i} : T_{i}

In either case,

k

must be nonnegative. If

D

has signature

\vec{κ} \Rightarrow ⋆

, then the type variables

\vec{X}

must have kind

\vec{κ}

. Every

T_{i}

must have kind

⋆

. We refer to

\bar{X}

as the parameters and to

\vec{T}

(the vector formed by

T_{1}, \dots, T_{k}

) as the components of the definition. The parameters are bound within the components, and the definition must be closed, that is,

f t v (\vec{T}) \subseteq \bar{x}

must hold. Last, for an algebraic data type definition to be valid, the behavior of the type constructor

D

with respect to subtyping must match its definition. This requirement is clarified below.

1.9.8 Definition: Consider an algebraic data type definition whose parameters and components are respectively

\vec{X}

and

\vec{T}

. Let

{\vec{X}}^{'}

and

{\vec{T}}^{'}

be their images under an arbitrary renaming. Then,

D \vec{X} \leq D {\vec{X}}^{'} ⊩ \vec{T} \leq {\vec{T}}^{'}

must hold.

The above requirement bears on the definition of subtyping in the model. The idea is, since

D \vec{X}

is declared to be isomorphic to (a sum or a product of)

\vec{T}

, whenever two types built with

D

are comparable, their unfoldings should be comparable as well. The reverse entailment assertion is not required for type soundness, and it is sometimes useful to declare algebraic data types that do not validate it-so-called phantom types (Fluet and Pucella, 2002). Note that the requirement may always be satisfied by making the type constructor

D

invariant in all of its parameters. Indeed, in that case,

D \vec{X} \leq D {\vec{X}}^{'}

entails

\vec{X} = {\vec{X}}^{'}

, which must entail

\vec{T} = {\vec{T}}^{'}

since

{\vec{T}}^{'}

is precisely

[\vec{X} \mapsto \vec{X^{'}}] \vec{T}

. In an equality free tree model, every type constructor is naturally invariant, so the requirement is trivially satisfied. In other settings, however, it is often possible to satisfy the requirement of Definition 1.9 .8 while assigning

D

a less restrictive variance. The following example illustrates such a case.

1.9.9 Example: Let list be a data type of signature

⋆ \Rightarrow ⋆

. Let Nil and Cons be data constructors. Then, the following is a definition of list as a variant type:

list X \approx Σ (N i l : unit; Cons : X \times list X)

Because data types form a subset of type constructors, it is valid to form the type list

X

in the right-hand side of the definition, even though we are still in the process of defining the meaning of list. In other words, data type definitions may be recursive. However, because

\approx

is not interpreted as equality, the type list

X

is not a recursive type: it is nothing but an application of the unary type constructor list to the type variable

X

. To check that the definition of list satisfies the requirement of Definition 1.9.8, we must ensure that

list X \leq list X^{'} ⊩ unit \leq unit \land X \times list X \leq X^{'} \times list X^{'}

holds. This assertion is equivalent to list

X \leq

list

X^{'} ⊩ X \leq X^{'}

. To satisfy the requirement, it is sufficient to make list a covariant type constructor, that is, to define subtyping in the model so that list

X \leq

list

X^{'} \equiv X \leq X^{'}

holds.

Let tree be a data type of signature

⋆ \Rightarrow ⋆

. Let root and sons be record labels. Then, the following is a definition of tree as a record type:

tree X \approx Π (root : X; sons : list (tree X))

This definition is again recursive, and relies on the previous definition. Because list is covariant, it is straightforward to check that the definition of tree is valid if tree is made a covariant type constructor as well.

1.9.10 EXERCISE

[⋆ ⋆, ↛]

: Consider a nonrecursive algebraic data type definition, where the variance of every type constructor that appears on the right-hand side is known. Can you systematically determine, for each of the parameters, the least restrictive variance that makes the definition valid? Generalize this procedure to the case of recursive and mutually recursive algebraic data type definitions.

A prologue is a set of algebraic data type definitions, where each data type is defined at most once and where each data constructor or record label appears at most once. A program is a pair of a prologue and an expression. The effect of a prologue is to enrich the programming language with new constants. That is, a variant type definition extends the operational semantics with several injections and a case construct, as in Example 1.2.7. A record type definition extends it with a record formation construct and several projections, as in Examples 1.2.3 and 1.2.5. In either case, the initial typing environment

Γ_{0}

is extended with information about these new constants. Thus, algebraic data type definitions might be viewed as a simple configuration language that allows specifying in which instance of ML-the-calculus the expression that follows the prologue should be typechecked and interpreted. Let us now give a precise account of this phenomenon.

To begin, suppose the prologue contains the definition

D \vec{X} \approx \sum_{i = 1}^{k} ℓ_{i} : T_{i}

. Then, for each

i \in {1, \dots, k}

, a constructor of arity 1 , named

ℓ_{i}

, is introduced. Furthermore, a destructor of arity

k + 1

, named case D

_{D}

, is introduced. When

k > 0

, it is common to write case

t {[ℓ_{i} : t_{i}]}_{i = 1}^{k}

for the application case

_{D} t t_{1} \dots t_{n}

. The operational semantics is extended with the following reduction rules, for

i \in {1, \dots, k}

\begin{matrix} (R-ALG-CASE) & case (ℓ_{i} v) {[ℓ_{j} : v_{j}]}_{j = 1}^{k} \overset{δ}{\to} v_{i} v \end{matrix}

For each

i \in {1, \dots, k}

, the initial environment is extended with the binding

ℓ_{i} : \forall \bar{X} . T_{i} \to D \vec{X}

. It is further extended with the binding case

D_{D} : \forall \bar{X} Z . D \vec{X} \to

(T_{1} \to Z) \to \dots (T_{k} \to Z) \to Z

Now, suppose the prologue contains the definition

D \vec{X} \approx \prod_{i = 1}^{k} ℓ_{i} : T_{i}

. Then, for each

i \in {1, \dots, k}

, a destructor of arity 1 , named

ℓ_{i}

, is introduced. Furthermore, a constructor of arity

k

, named make

e_{D}

, is introduced. It is common to write

t . ℓ

for the application

ℓ t

and, when

k > 0

, to write

{ℓ_{i} = t_{i}}_{i = 1}^{k}

for the application make

t_{D} \dots t_{k}

. The operational semantics is extended with the following reduction rules, for

i \in {1, \dots, k}

\begin{matrix} (R-ALG-PRoJ) & ({ℓ_{j} = v_{j}}_{j = 1}^{k}) \cdot ℓ_{i} \overset{δ}{\to} v_{i} \end{matrix}

For each

i \in {1, \dots, k}

, the initial environment is extended with the binding

ℓ_{i} : \forall \bar{X} . D \vec{X} \to T_{i}

. It is further extended with the binding make

D_{D} : \forall \bar{X} . T_{1} \to \dots \to

T_{k} \to D \vec{X}

1.9.11 EXAMPLE: The effect of defining list (Example 1.9.9) is to make Nil and Cons data constructors of arity 1 and to introduce a binary destructor case list . The definition also extends the initial environment as follows:

Thus, the value Cons

(\hat{0}, N i l ())

, an integer list of length 1 , has type list int. A function that computes the length of a list may now be written as follows:

letrec length = λ l . case 1 [N i l : λ_. \hat{0} ∣ Cons : λ z . \hat{1} \hat{+} length (π_{2} z)]

Recall that this notation is syntactic sugar for

letrec length = λ {l.case}_{list} l (λ_. \hat{0}) (λ z . \hat{1} \hat{+} length (π_{2} z))

The difference with the code in Example 1.9.7 appears minimal: the case construct is now annotated with the data type list. As a result, the type inference algorithm employs the type scheme assigned to case list , which is derived from the definition of list, instead of the type scheme assigned to the anonymous case construct, given in Exercise 1.9.4. This is good for a couple of reasons. First, the former is more informative than the latter, because it contains the type

T_{i}

associated with the data constructor

ℓ_{i}

. Here, for instance, the generated constraint requires the type of

z

to be

X \times

list

X

for some

X

, so a good error message would be given if a mistake was made in the second branch, such as omitting the use of

π_{2}

. Second, and more fundamentally, the code is now well-typed, even in the absence of recursive types. In Example 1.9.7, a cyclic equation was produced because case required the type of 1 to be a sum type and because a sum type carries the types of its left and right branches as subterms. Here, instead, case list requires 1 to have type list X for some X. This is an abstract type: it does not explicitly contain the types of the branches. As a result, the generated constraint no longer involves a cyclic equation. It is, in fact, satisfiable; the reader may check that length has type

\forall x

. list

X \to

int, as expected.

Example 1.9.11 stresses the importance of using declared, abstract types, as opposed to anonymous, concrete sum or product types, in order to obviate the need for recursive types. The essence of the trick lies in the fact that the type schemes associated with operations on algebraic data types implicitly fold and unfold the data type's definition. More precisely, let us recall the type scheme assigned to the

i^{th}

injection in the setting of (

k

-ary) anonymous sums: it is

\forall X_{1} \dots X_{k} \cdot X_{i} \to X_{1} + \dots + X_{k}

, or, more concisely,

\forall x_{1} \dots X_{k} . X_{i} \to \sum_{i = 1}^{k} X_{i}

. By instantiating each

X_{i}

with

T_{i}

and generalizing again, we find that a more specific type scheme is

\forall \bar{X} . T_{i} \to \sum_{i = 1}^{k} T_{i}

. Perhaps this could have been the type scheme assigned to

ℓ_{i}

? Instead, however, it is

\forall \bar{X}

T_{i} \to D \vec{X}

. We now realize that this type scheme not only reflects the operational behavior of the

i^{th}

injection, but also folds the definition of the algebraic data type

D

by turning the anonymous sum

\sum_{i = 1}^{k} T_{i}

-which forms the definition's right-hand side-into the parameterized abstract type

D \vec{X}

- which is the definition's left-hand side. Conversely, the type scheme assigned to case

_{D}

unfolds the definition. The
situation is identical in the case of record types: in either case, constructors fold, destructors unfold. In other words, occurrences of data constructors and record labels in the code may be viewed as explicit instructions for the typechecker to fold or unfold an algebraic data type definition. This mechanism is characteristic of isorecursive types.

1.9.12 EXERCISE

[⋆, ↛]

: For a fixed

k

, check that all of the machinery associated with

k

-ary anonymous products - that is, constructors, destructors, reduction rules, and extensions to the initial typing environment-may be viewed as the result of a single algebraic data type definition. Conduct a similar check in the case of

k

-ary anonymous sums.

1.9.13 EXERCISE

[⋆ ⋆ ⋆, ↛]

: Check that the above definitions meet the requirements of Definition 1.7.6.

1.9.14 EXERCISE

[⋆ ⋆ ⋆, ↛]

: For sake of simplicity, we have assumed that data constructors are always of arity one. It is indeed possible to allow data constructors of any arity and define variants as

D \vec{X} \approx \sum_{i = 1}^{k} ℓ_{i} : {\vec{T}}_{i}

. For instance, the definition of list could then be list

X \approx Σ (N i l

; Cons

: X \times

list

X)

and for instance

Cons (\hat{0}, N i l)

would be a list value. Make the necessary changes in the definitions above and check that they still meet the requirements of Definition 1.7.6.

In this formal presentation of algebraic data types, we have assumed that all algebraic data type definitions are known before the program is typechecked. This simplifying assumption is forced on us by the fact that we interpret constraints in a fixed model, that is, we assume a fixed universe of types. In practice, programming languages have module systems, which allow distinct modules to have distinct, partial views of the universe of types. Then, it becomes possible for each module to come with its own data type definitions. Interestingly, it is even possible, in principle, to split the definition of a single data type over several modules, yielding extensible algebraic data types. For instance, module

A

might declare the existence of a parameterized variant type

D \vec{x}

, without giving its components. Later on, module

B

might define a component

ℓ : T

, where

f t v (T) \subseteq \bar{X}

. Such a definition makes

ℓ

a unary constructor with type scheme

\forall \bar{X} . T \to D \vec{X}

, as before. It becomes impossible, however, to introduce a destructor

{c a s e}_{D}

, because the definition of an extensible variant type can never be assumed to be complete-other, unknown modules might extend it further. To compensate for its absence, one may supplement every constructor

ℓ

with a destructor

ℓ^{- 1}

, whose semantics is given by

ℓ^{- 1} (ℓ v) v_{1} v_{2} \overset{δ}{\to} v_{1} v

and

ℓ^{- 1} (ℓ^{'} v) v_{1} v_{2} \overset{δ}{\to} v_{2} (ℓ^{'} v)

when

ℓ \neq ℓ^{'}

, and whose type scheme is

\forall \bar{x} Z . D \vec{X} \to (T \to Z) \to (D \vec{X} \to Z) \to Z

. When
pattern matching is available,

ℓ^{- 1}

may in fact be defined in the language. MLthe-programming-language does not offer extensible algebraic data types as a language feature, but does have one built-in extensible variant type, namely the type exn of exceptions. Thus, it is possible to define new constructors for the type exn within any module. The price of this extra flexibility is that no exhaustive case analysis on values of type exn is possible.

One significant drawback of algebraic data type definitions resides in the fact that a label

ℓ

cannot be shared by two distinct variant or record type definitions. Indeed, every algebraic data type definition extends the calculus with new constants. Strictly speaking, our presentation does not allow a single constant

c

to be associated with two distinct definitions. Even if we did allow such a collision, the initial environment would contain two bindings for c, one of which would then become inaccessible. This phenomenon arises in actual implementations of ML-the-programming-language, where a new algebraic data type definition may hide some of the data constructors or record labels introduced by a previous definition. An elegant solution to this lack of expressiveness is discussed in Section 1.11.

Pattern matching

Our presentation of products, sums and algebraic data types has remained within the setting of ML-the-calculus: that is, data structures have been built out of constructors, while the case analysis and record access operations have been viewed as destructors. Some syntactic sugar has been used to recover standard notations. The language is now expressive enough to allow defining and manipulating complex data structures, such as lists and trees. Yet, experience shows that programming in such a language is still somewhat cumbersome. Indeed, case analysis and record access are low-level operations: the former allows inspecting a tag and branching, while the latter allows dereferencing a pointer. In practice, one often needs to carry out more complex tasks, such as determining whether a data structure has a certain shape or whether two data structures have comparable shapes. Currently, the only way to carry out these tasks is to program an explicit sequence of low-level operations. It would be much preferable to extend the language so that it becomes directly possible to describe shapes, called patterns, and so that checking whether a patterns matches a value becomes an elementary operation. ML-the-programming-language offers this feature, called pattern matching. Although pattern matching may be added to ML-the-calculus by introducing a family of destructors, we rather choose to extend the calculus with a new match construct, which subsumes the existing let construct. This approach appears somewhat simpler and more powerful. We now carry out this

Figure 1-13: Patterns and pattern matching

extension.

Let us first define the syntax of patterns (Figure 1-13) and describe (informally, for now) which values they match. To a pattern

p

, we associate a set of defined program variables

d p i (p)

, whose definition appears in the text that follows. The pattern

p

is well-formed if and only if

d p i (p)

is defined. To begin, the wildcard _ is a pattern, which matches every value and binds no variables. We let

d p i (_) = \emptyset

. Although the wildcard may be viewed as an anonymous variable, and we have done so thus far, it is now simpler to view it as a distinct pattern. A program variable

z

is also a pattern, which matches every value and binds

z

to the matched value. We let

d p i (z) = {z}

. Next, if

c

is a constructor of arity

k

, then

c p_{1} \dots p_{k}

is a pattern, which matches

c v_{1} \dots v_{k}

when

p_{i}

matches

v_{i}

for every

i \in {1, \dots, k}

. We let

d p i (c_{1} \dots p_{k}) = d p i (p_{1}) ⊎ \dots ⊎ d p i (p_{k})

. That is, the pattern

c p_{1} \dots p_{k}

is well-formed when

p_{1}, \dots, p_{k}

define disjoint sets of variables. This condition rules out nonlinear patterns such as

(z, z)

. Defining the semantics of such a pattern would require a notion of equality at every type, which introduces various complications, so it is commonly considered ill-formed. The pattern

p_{1} \land p_{2}

matches all values that both

p_{1}

and

p_{2}

match. It is commonly used with

p_{2}

a program variable: then, it allows examining the shape of a value and binding a name to it at the same time. Again, we define

d p i (p_{1} \land p_{2}) = d p i (p_{1}) ⊎ d p i (p_{2})

. The pattern

p_{1} \lor p_{2}

matches all values that either

p_{1}

p_{2}

matches. We define

d p i (p_{1} \lor p_{2}) = d p i (p_{1}) = d p i (p_{2})

. That is, the pattern

p_{1} \lor p_{2}

is well-formed when

p_{1}

and

p_{2}

define the same variables. Thus,

(i n j_{1} z) \lor (i n j_{2} z)

is a wellformed pattern, which binds

z

to the component of a binary sum, without regard for its tag. However,

(i n j_{1} z_{1}) \lor (i n j_{2} z_{2})

is ill-formed, because one cannot statically predict whether it defines

z_{1}

z_{2}

Let us now formally define whether a pattern

p

matches a value

v

and how the variables in

d p i (p)

become bound to values in the process. This is done by introducing a generalized substitution, written

[p \mapsto v]

, which is either

undefined or a substitution of values for the program variables in

d p i (p)

. If the former, then

p

does not match

v

. If the latter, then

p

matches

v

and, for every

z \in d p i (p)

, the variable

z

becomes bound to the value

[p \mapsto v] z

. Of course, when

p

is a variable

z

, the generalized substitution

[z \mapsto v]

is defined and coincides with the substitution

[z \mapsto v]

, which justifies our abuse of notation. To construct generalized substitutions, we use two simple combinators. First, when

dpi (p_{1})

and

dpi (p_{2})

are disjoint,

[p_{1} \mapsto v_{1}] \otimes [p_{2} \mapsto v_{2}]

stands for the set-theoretic union of

[p_{1} \mapsto v_{1}]

and

[p_{2} \mapsto v_{2}]

, if both are defined, and is undefined otherwise. We use this combinator to ensure that

p_{1}

matches

v_{1}

and

p_{2}

matches

v_{2}

and to combine the two corresponding sets of bindings. Second, when

o_{1}

and

o_{2}

are two possibly undefined mathematical objects that belong to the same space when defined,

o_{1} \oplus o_{2}

stands for

o_{1}

, if it is defined, and for

o_{2}

otherwise - that is,

\oplus

is an angelic choice operator with a left bias. In particular, when

d p i (p_{1})

and

d p i (p_{2})

coincide,

[p_{1} \mapsto v_{1}] \oplus [p_{2} \mapsto v_{2}]

stands for

[p_{1} \mapsto v_{1}]

, if it is defined, and for

[p_{2} \mapsto v_{2}]

otherwise. We use this combinator to ensure that

p_{1}

matches

v_{1}

p_{2}

matches

v_{2}

and to retain the corresponding set of bindings. The full definition of generalized substitutions, which relies on these combinators, appears in Figure 1-13. It reflects the informal presentation of the previous paragraph.

Once patterns and pattern matching are defined, it is straightforward to extend the syntax and operational semantics of ML-the-calculus. We enrich the syntax of expressions with a new construct, match

t

with

{(p_{i} \cdot t_{i})}_{i = 1}^{k}

, where

k \geq 1

. It consists of a term

t

and a nonempty, ordered list of clauses, each of which is composed of a pattern

p_{i}

and a term

t_{i}

. The syntax of evaluation contexts is extended as well, so that the term

t

that is being examined is first reduced to a value

v

. The operational semantics is extended with a new rule,

R - M A T C H

, which states that match

v

with

{(p_{i} \cdot t_{i})}_{i = 1}^{k}

reduces to

[p_{i} \mapsto v] t_{i}

, where

i

is the least element of

{1, \dots, k}

such that

p_{i}

matches

v_{i}

. Technically,

⨁_{i = 1}^{k} [p_{i} \mapsto v] t_{i}

stands for

[p_{1} \mapsto v] t_{1} \oplus \dots \oplus [p_{k} \mapsto v] t_{k}

, so that the reduct is the first term that is defined in this sequence.

As far as semantics is concerned, the match construct may be viewed as a
generalization of the let construct. Indeed, let

z = t_{1}

t_{2}

may now be viewed as syntactic sugar for match

t_{1}

with

z . t_{2}

, that is, a match construct with a single clause and a variable pattern. Then, R-LET becomes a special case of R-MATCH.

It is pleasant to introduce some more syntactic sugar. We write

λ {(p_{i} \cdot t_{i})}_{i = 1}^{k}

for

λ

z.match

z

with

{(p_{i} \cdot t_{i})}_{i = 1}^{k}

, where

z

is fresh for

{(p_{i} \cdot t_{i})}_{i = 1}^{k}

. Thus, it becomes possible to define functions by cases - a common idiom in ML-theprogramming-language.

1.9.15 EXAMPLE: Using pattern matching, a function that computes the length of a list (Example 1.9.11) may now be written as follows:

letrec length = λ ({N i l}_{\dots} . \hat{0} ∣ Cons (_, z) . \hat{1} \hat{+} length z)

The second pattern matches a nonempty list and binds

z

to its tail at the same time, obviating the need for an explicit application of

π_{2}

1.9.16 Exercise

[⋆ ⋆

, Recommended,

↛

]: Under the above definition of length, consider an application of length to the list Cons(

\hat{0}, N i l ())

. After eliminating the syntactic sugar, determine by which reduction sequence this expression reduces to a value.

Before we can proceed and extend the type system to deal with the new match construct, we must make two mild extensions to the syntax and meaning of constraints. First, if

σ

\forall \bar{X} [C]

.T, where

\bar{X} # f t v (T^{'})

, then

T^{'} ⪯ σ

stands for the constraint

\exists \bar{X} . (C \land T^{'} \leq T)

. This relation is identical to the instance relation (Definition 1.3.3), except the direction of subtyping is reversed. We extend the syntax of constraints with instantiation constraints of the form

T ⪯ x

and define their meaning by adding a symmetric counterpart of CM-

INSTANCE. We remark that, when subtyping is interpreted as equality, the relations

σ ⪯ T

and

T ⪯ σ

coincide, so this extension is unnecessary in that particular case. Second, we extend the syntax of environments so that several successive bindings may share a set of quantifiers and a constraint. That is, we allow writing

\forall \bar{X} [C] . (x_{1} : T_{1}; \dots; x_{k} : T_{k})

for

x_{1} : \forall \bar{x} [C] . T_{1}; \dots; x_{k}

\forall \bar{X} [C] . T_{k}

. From a theoretical standpoint, this is little more than syntactic sugar; however, in practice, it is useful to implement this new idiom literally, since it avoids unnecessary copying of the constraint

C

Let us now extend the type system. For the sake of brevity, we extend the constraint generation rules only. Of course, it would also be possible to define corresponding extensions of the rule-based type systems shown earlier, namely

D M, HM (X)

, and

PCB (X)

. We begin by defining a constraint

[[T : p]]

that represents a necessary and sufficient condition for values of type

T

to be acceptable inputs for the pattern

p

. Its free type variables are a subset of

\begin{aligned} [[T :_]] = true \\ [[T : z]] = T ⪯ z \\ [[T : c p_{1} \dots p_{k}]] = \exists \bar{x} \cdot (\vec{x} \to T ⪯ c \land \land_{i = 1}^{k} [[x_{i} : p_{i}]]) \\ [[T : p_{1} \land p_{2}]] = [[T : p_{1}]] \land [[T : p_{2}]] \\ [[T : p_{1} \lor p_{2}]] = [[T : p_{1}]] \land [[T : p_{2}]] \\ [[matcht with {(p_{i} \cdot t_{i})}_{i = 1}^{k} : T]] = ⋀_{i = 1}^{k} let \forall x {\bar{x}}_{i} [[[t : x]] \land let {\vec{z}}_{i} : {\vec{x}}_{i} in [[x : p_{i}]]]] \cdot ({\vec{z}}_{i} : {\vec{x}}_{i}) in [[t_{i} : T]] \\ where {\vec{z}}_{i} = d p i (p_{i}) \end{aligned}

Figure 1-15: Constraint generation for patterns and pattern matching

f t v (T)

, while its free program identifiers are either constructors or program variables bound by

p

. It is defined in the upper part of Figure 1-15. The first rule states that a wildcard matches values of arbitrary type. The second and third rules govern program variables and constructor applications in patterns. They are identical to the rules that govern these constructs in expressions (page 59), except that the direction of subtyping is reversed. In the absence of subtyping, they would be entirely identical. We write

\vec{X}

for

X_{1} \dots X_{k}

and

\vec{X} \to T

for

X_{1} \to \dots \to X_{k} \to T

. As usual, the type variables

X_{1}, \dots, X_{k}

must have kind

⋆

and must be distinct and fresh for the equation's left-hand side. The last two rules simply distribute the type

T

to both subpatterns. It is easy to check that

[[T : p]]

is contravariant in

T

1.9.17 Lemma:

T^{'} \leq T \land [[T : p]]

entails

[[T^{'} : p]]

This property reflects the fact that

T

represents the type of an input for the pattern p. Compare it with Lemma 1.6.3.

1.9.18 Example: Consider the pattern Cons

(_{-}, z)

, which appears in Example 1.9.15. We have

\begin{aligned} [[T : Cons (- z)]] \\ \equiv & \exists Z_{1} \cdot ([[Z_{1} \to T : Cons]] \land [[Z_{1} : (, z)]]) \\ \equiv & \exists Z_{1} \cdot (Z_{1} \to T ⪯ Cons \land \exists Z_{2} Z_{3} \cdot ([[Z_{2} \to Z_{3} \to Z_{1} : (\cdot, \cdot)]] \land [[Z_{2} :_]] \land [[Z_{3} : z]])) \\ \equiv & \exists Z_{1} Z_{2} Z_{3} \cdot (Z_{1} \to T ⪯ Cons \land Z_{2} \to Z_{3} \to Z_{1} ⪯ (\cdot, \cdot) \land Z_{3} ⪯ z) \end{aligned}

where

Z_{1}, Z_{2}, Z_{3}

are fresh for

T

. Let us now place this constraint within the scope of the initial environment, which assigns type schemes to the constructors Cons and

(\cdot, \cdot)

, and within the scope of a binding of

z

to some type

T^{'}

We find

\begin{aligned} let Γ_{0} in let z : T^{'} in [[T : Cons (, z)]] \\ \equiv & \exists Z_{1} Z_{2} Z_{3} \cdot (\exists X \cdot (Z_{1} \to T \leq X \times list X \to list X) \land \\ \equiv & \exists Y_{1} Y_{2} \cdot (Z_{2} \to Z_{3} \to Z_{1} \leq Y_{1} \to Y_{2} \to Y_{1} \times Y_{2}) \land Z_{3} \leq T^{'}) \\ \equiv & \exists X \cdot (T \leq list X \land list X \leq T^{'}) \end{aligned}

where the final simplification relies mainly on C-ARROw, on the corresponding rule for products, and on C-ExTrans, and is left as an exercise to the reader. Thus, the constraint states that the pattern matches values that have type list

X

(equivalently, values whose type

T

is a subtype of list

X

), for some undetermined element type

X

, and binds

z

to values of type list

X

(equivalently, values whose type

T^{'}

is a supertype of list

X

The above example seems to indicate that the constraint generation rules for patterns make some sense. Still, the careful reader may be somewhat puzzled by the third rule, which, compared to its analogue for expressions, reverses the direction of subtyping, but does not reverse the direction of instantiation. Indeed, in order for this rule to make sense, and to be sound, we must formulate a requirement concerning the type schemes assigned to constructors.

1.9.19 Definition: A constructor

c

is invertible if and only if, when

\vec{X}

and

{\vec{X}}^{'}

have length

a (c)

, the constraint let

Γ_{0}

({\vec{X}}^{'} \to T ⪯ c \land c ⪯ \vec{X} \to T)

entails

\vec{X} \leq {\vec{X}}^{'}

. In the following, we assume patterns contain invertible constructors only.

Intuitively, when

c

is invertible, it is possible to recover the type of every

v_{i}

from the type of

c v_{1} \dots v_{k}

, a crucial property for pattern matching to be possible. Please note that, if

Γ_{0} (c)

is monomorphic, then

c

is invertible. The following lemma identifies another important class of invertible constructors.

1.9.20 Lemma: The constructors of algebraic data types are invertible.

Proof: Let

c

be a constructor introduced by the definition of an algebraic data type D. Let

k = a (c)

. Then, the type scheme

Γ_{0} (c)

is of the form

\forall \bar{Y} . \vec{T} \to D \vec{Y}

, where

\vec{Y}

are the parameters of the definition and

\vec{T}

, a vector of length

k

, consists of some of the definition's components. (More precisely,

\vec{T}

contains just one component in the case of variant types and contains all components in the case of record types.) Let

\vec{X}

and

{\vec{X}}^{'}

have length

k

. Let

\forall {\vec{Y}}_{1} \cdot {\vec{T}}_{1} \to D {\vec{Y}}_{1}

and

\forall {\bar{Y}}_{2} \cdot {\vec{T}}_{2} \to D {\vec{Y}}_{2}

be two

α

-equivalent forms of the type scheme

Γ_{0} (c)

, with

{\bar{Y}}_{1} # {\bar{Y}}_{2}

and

{\bar{Y}}_{1} {\bar{Y}}_{2} # ftv (\bar{X}, {\bar{X}}^{'}, T)

. The constraint let

Γ_{0}

({\vec{X}}^{'} \to T ⪯ c \land c ⪯

\vec{X} \to T

) is, by definition, equivalent to

{\vec{X}}^{'} \to T ≺ Γ_{0} (c) \land Γ_{0} (c) ≺ \vec{X} \to T

, that is,

\exists {\bar{Y}}_{1} \cdot ({\vec{X}}^{'} \to T \leq {\vec{T}}_{1} \to D {\vec{Y}}_{1}) \land \exists {\bar{Y}}_{2} \cdot ({\vec{T}}_{2} \to D {\vec{Y}}_{2} \leq \vec{X} \to T)

. By C-ExAND and CARRow, this may be written

\exists {\bar{Y}}_{1} {\bar{Y}}_{2} \cdot (D {\vec{Y}}_{2} \leq T \leq D {\vec{Y}}_{1} \land \vec{X} \leq {\vec{T}}_{2} \land {\vec{T}}_{1} \leq {\vec{X}}^{'})

. Now,
by Definition 1.9.8, D

{\vec{Y}}_{2} \leq D {\vec{Y}}_{1}

entails

{\vec{T}}_{2} \leq {\vec{T}}_{1}

, so the previous constraint entails

\exists {\bar{Y}}_{1} {\bar{Y}}_{2} \cdot (\vec{X} \leq {\vec{X}}^{'})

, that is,

\vec{X} \leq {\vec{X}}^{'}

An important class of noninvertible constructors are those associated with existential type definitions (page 118), where not all quantifiers of the type scheme

Γ_{0} (c)

are parameters of the type constructor D. For instance, under the definition

D \approx ℓ : \exists X . X

, the type scheme associated with

ℓ

\forall X . X \to D

. Then, it is easy to check that

ℓ

is not invertible. This reflects the fact that it is not possible to recover the type of

v

from the type of

ℓ v

-which must be

D

in any case-and explains why existential types require special treatment.

We are now ready to associate a constraint generation rule with the match construct. It is given in the lower part of Figure 1-15. In the rule's right-hand side, we write

{\vec{z}}_{i}

for the program variables bound by the pattern

p_{i}

, and we write

{\vec{X}}_{i}

for a vector of type variables of the same length. The type variables

X {\bar{X}}_{i}

must have kind

⋆

, must be pairwise distinct and must not appear free in the rule's left-hand side. Let us now explain the rule. Its right-hand side is a conjunction, where each conjunct deals with one clause of the match construct, requiring

t_{i}

to have type

T

under certain assumptions about the program variables

{\vec{z}}_{i}

bound by the pattern

p_{i}

. There remains to explain how these assumptions are built. First, as in the case of a let construct, we summon a fresh type variable

X

and produce

[[t : x]]

, the least specific constraint that guarantees

t

has type

X

. Then, reflecting the operational semantics, which feeds (the value produced by)

t

into the pattern

p_{i}

, we feed the type

X

into

p_{i}

and produce let

{\vec{z}}_{i} : {\vec{X}}_{i}

[[X : p_{i}]]

, a constraint that guarantees that

{\vec{X}}_{i}

is a correct vector of type assumptions for the program variables

{\vec{z}}_{i}

(see Example 1.9.18). This explains why we may place

[[T : t_{i}]]

within the scope of

({\vec{z}}_{i} : {\vec{x}}_{i})

. There remains to point out that, as in the case of the let construct, every assignment of ground types to

X {\bar{X}}_{i}

that satisfies the constraint

[[t : X]] \land

let

{\vec{z}}_{i} : {\vec{X}}_{i}

[[X : p_{i}]]

is acceptable, so it is valid to universally quantify these type variables. This allows the program variables

{\vec{z}}_{i}

to receive polymorphic type schemes when

t

itself has polymorphic type.

1.9.21 Exercise [

⋆

, Recommended]: We have previously suggested viewing let

z = t_{1}

t_{2}

as syntactic sugar for match

t_{1}

with

z . t_{2}

, and shown that the operational semantics validates this view. Check that it is also valid from a typing perspective.

The match constraint generation rule, if implemented literally, takes

k

copies of the constraint

[[t : x]]

. When

k

is greater than 1 , this compromises the linear time and space complexity of constraint generation. To remedy this problem, one may modify the rule as follows: replace every copy of

[[t : x]]

with

z ⪯ x

and place the constraint within the context let

z : \forall x [[[t : x]]] . x

in [] , where

z

is
a fresh program variable. It is not difficult to check that the logical meaning of the constraint is not affected and that a linear behavior is recovered. In practice, solving the new constraint requires taking instances of the type scheme

\forall x [[[t : x]]] . x

, which essentially requires copying

[[t : x]]

again-however, an efficient solver may now simplify this subconstraint before duplicating it.

The following lemma is a key to establishing subject reduction for RMATCH. It relies on the requirement that constructors be invertible.

1.9.22 Lemma: Assume

[p \mapsto v]

is defined and maps

\vec{z}

\vec{w}

, where

\bar{z} = d p i (p)

. Let

\vec{z} : \vec{T}

be an arbitrary monomorphic environment of domain

\bar{z}

. Then, let

Γ_{0}

([[v : T]] \land

let

\vec{z} : \vec{T}

[[T : p]])

entails let

Γ_{0}

[[\vec{w} : \vec{T}]]

We now prove that our extension of ML-the-calculus with pattern matching enjoys subject reduction. We only state that R-MATCH preserves types, and leave the new subcase of R-CONTEXT, where the evaluation context involves a match construct, to the reader. For this subcase to succeed, the value restriction (Definition 1.7.7) must be extended to require that either all constants have pure semantics or all match constructs are in fact of the form match v with

{(p_{i} \cdot t_{i})}_{i = 1}^{k}

1.9.23 ThEOREM [SUBJECT REDUCTION]: (R-MATCH) $\subseteq (⊑)$

1.9.24 ExERcise

[⋆ ⋆ ⋆, ↛]

: For the sake of simplicity, we have omitted the production ref

p

from the syntax of patterns. The pattern ref

p

matches every memory location whose content (with respect to the current store) is matched by p. Determine how the previous definitions and proofs must be extended in order to accommodate this new production.

The progress property does not hold in general: for instance, match Nil with (Cons z.z) is well-typed (with type

\forall

X.X) but is stuck. In actual implementations of ML-the-programming-language, such errors are dynamically detected. This may be considered a weakness of ML-the-typesystem. Fortunately, however, it is often possible to statically prove that a particular match construct is exhaustive and cannot go wrong. Indeed, if match

v

with

{(p_{i} \cdot t_{i})}_{i = 1}^{k}

is well-typed, then for every

i \in {1, \dots, k}

, the constraint let

Γ_{0}

([[v : X]] \land \exists \bar{X}

. let

{\vec{z}}_{i} : \vec{X}

[[X : p_{i}]])

, where

{\bar{z}}_{i}

are the program variables bound by

p_{i}

, must be satisfiable; that is,

v

must have some type that is an acceptable input for

p_{i}

. This fact yields information about

v

, from which it may be possible to derive that

v

must match one of the patterns

p_{i}

1.9.25 ExAmple: Let

k = 2, p_{1} = N i l

, and

p_{2} =

Cons

(z_{1}, z_{2})

. Then, the constraints let

Γ_{0}

\exists \bar{X}

.let

{\vec{z}}_{i} : \vec{X}

[[X : p_{i}]]

, for

i \in {1, 2}

, are both equivalent (after simplification, when

i = 2

) to

\exists Z

X \leq

list

Z

. Because the type constructor list is isolated, every closed value

v

whose type

X

satisfies this constraint
must be an application of

N i l

or Cons. If the latter, because Cons has type

\forall X . X \times

list

X \to

list

X

, and because the type constructor

\times

is isolated, the argument to Cons must be a pair. We conclude that

v

must match either

p_{1}

p_{2}

, which guarantees that this match construct is exhaustive and its evaluation cannot go wrong.

It is beyond the scope of this chapter to give more details about the check for exhaustiveness. The reader is referred to (Sekar, Ramesh, and Ramakrishnan, 1995; Le Fessant and Maranget, 2001).

Type annotations

So far, we have been interested in a very pure, and extreme, form of type inference. Indeed, in ML-the-calculus, expressions contain no explicit type information whatsoever: it is entirely inferred. In practice, however, it is often useful to insert type annotations within expressions, because they provide a form of machine-checked documentation. Type annotations are also helpful when attempting to trace the cause of a type error: by supplying the typechecker with (supposedly) correct type information, one runs a better chance of finding a type inconsistency near an actual programming mistake.

When type annotations are allowed to contain type variables, one must be quite careful about where (at which program point) and how (existentially or universally) these variables are bound. Indeed, the meaning of type annotations cannot be made precise without settling these issues. In what follows, we first explain how to introduce type annotations whose type variables are bound locally and existentially. We show that extending ML-the-calculus with such limited type annotations is again a simple matter of introducing new constants. Then, we turn to a more general case, where type variables may be explicitly existentially introduced at any program point. We defer the discussion of universally bound type variables to Section 1.10.

Let a local existential type annotation

\exists \bar{X}

T

be a pair of a set of type variables

\bar{X}

and a type

T

, where

T

has kind

⋆, \bar{X}

is considered bound within

T

, and

\bar{X}

contains

f t v (T)

. For every such annotation, we introduce a new unary destructor

(\cdot : \exists \bar{X} . T)

. Such a definition is valid only because a type annotation must be closed, that is, does not have any free type variables. We write

(t : \exists \bar{X} . T)

for the application

((\cdot : \exists \bar{X} . T)) t

. Since a type annotation does not affect the meaning of a program, the new destructor has identity semantics:

(v : \exists \bar{X} . T) \overset{δ}{\to} v

(R-AnNotation)

Its type scheme, however, is not that of the identity, namely

\forall X . X \to X

: instead, it is less general, so that annotating an expression restricts its type. Indeed,
we extend the initial environment

Γ_{0}

with the binding

(\cdot : \exists \bar{X} . T) : \forall \bar{X} . T \to T

1.9.26 EXERCISE [

⋆

]: Check that

\forall \bar{X} . T \to T

is an instance of

\forall X . X \to X

in Damas and Milner's sense, that is, the former is obtained from the latter via the rule DM-INST' given in Exercise 1.2.23. Does this allow arguing that the type scheme assigned to

(\cdot : \exists \bar{X} . T)

is sound? Check that the above definitions meet the requirements of Definition 1.7.6.

Although inserting a type annotation does not change the semantics of the program, it does affect constraint generation, hence type inference. We let the reader check that, assuming

\bar{X} # f t v (t, T^{'})

, the following derived constraint generation rule holds:

let Γ_{0} in [[(t : \exists \bar{X} . T) : T^{'}]] \equiv let Γ_{0} in \exists \bar{X} \cdot ([[t : T]] \land T \leq T^{'})

So far, expressions cannot have free type variables, so the hypothesis

\bar{x}

f t v (t)

may seem superfluous. However, we shall soon allow expressions to contain type annotations with free type variables, so we prefer to make this condition explicit now. According to this rule, the effect of the type annotation is to force the expression

t

to have type

T

, for some choice of the type variables

\bar{X}

. As usual in type systems with subtyping, the expression's final type

T^{'}

may then be an arbitrary supertype of this particular instance of

T

. When subtyping is interpreted as equality,

T^{'}

and

T

are equated by the constraint, so this constraint generation rule may be read: a valid type for (

t : \exists \bar{X} T

) must be of the form

T

, for some choice of the type variables

\bar{x}

1.9.27 Example: In DM extended with integers, the expression (

λ z . z :

int

\to

int) has most general type int

\to

int, even though the underlying identity function has most general type

\forall X . X \to X

, so the annotation restricts its type. The expression

(λ z . z \hat{+} \hat{1} : \exists X . X \to X)

has type int

\to

int, which is also the most general type of the underlying function, so the annotation acts merely as documentation in this case. Note that the type variable

X

is instantiated to int by the constraint solver. The expression

(λ z . (z \hat{1}) : \exists X . X \to

int) has type (int

\to

int)

\to

int because the underlying function has type (int

\to Y) \to Y

, which successfully unifies with

X \to

int by instantiating

X

to int

\to

int and

Y

to int. Last, the expression (

λ z \cdot (z \hat{1}) : \exists X

.int

\to X

) is ill-typedeven though the underlying expression is well-typed-because the equation (int

\to Y) \to Y =

int

\to X

is unsatisfiable.

1.9.28 ExAmple: In DM extended with pairs, the expression

λ z_{1} \cdot λ z_{2} \cdot ((z_{1} :

\exists X . X), (z_{2} : \exists X . X))

has most general type

\forall X Y . X \to Y \to X \times Y

. In other words, the two occurrences of

X

do not represent the same type. Indeed, one could just as well have written

λ z_{1} \cdot λ z_{2} \cdot ((z_{1} : \exists X . X), (z_{2} : \exists Y . Y))

. If one wishes

z_{1}

and

z_{2}

to receive the same type, one must lift the type annotations and merge them above the pair constructor, as follows:

λ z_{1} \cdot λ z_{2} \cdot ((z_{1}, z_{2}) : \exists X . X \times X)

. In the process, the type constructor

x

has appeared in the annotation, causing its size to increase.

The above example reveals a limitation of this style of type annotations: by requiring every type annotation to be closed, we lose the ability for two separate annotations to share a type variable. Yet, such a feature is sometimes desirable. If the two annotations where sharing is desired are distant in the code, it may be awkward to lift and merge them into a single annotation; so, more expressive power is sometimes truly needed.

Thus, we are lead to consider more general type annotations, of the form

(t : T)

, where

T

has kind

⋆

, and where the type variables that appear within

T

are considered free, so that distinct type annotations may refer to shared type variables. For this idea to make sense, however, it is still necessary to specify where these type variables are bound. We do so using expressions of the form

\exists \bar{X}

.t. Such an expression binds the type variables

\bar{X}

within the expression

t

, so that all free occurrences of

X

(where

X \in \bar{X}

) in type annotations inside

t

stand for the same type. Thus, we break the simple type annotation construct

(\cdot : \exists \bar{X}

.T) into two more elementary constituents, namely existential type variable introduction

\exists \bar{X} \cdot

and type constraint

(\cdot : T)

. Note that both are new forms of expressions; neither can be encoded by adding new constants to the calculus, because it is not possible to assign closed type schemes to them.

Technically, allowing expressions to contain type variables requires some care. Several constraint generation rules employ auxiliary type variables, which become bound in the generated constraint. These type variables may be chosen in an arbitrary way, provided they do not appear free in the rule's left-hand side - a side-condition intended to avoid inadvertent capture. So far, this side-condition could be read: the auxiliary type variables used to form the constraint

[[t : T]]

must not appear free within

T

. Now, since type annotations may contain free type variables, the side-condition becomes: the auxiliary type variables used to form

[[t : T]]

must not appear free within

t

T

With this extended side-condition in mind, our original constraint generation rules remain unchanged. We add two new rules to describe how the new expression forms affect constraint generation:

\begin{aligned} [[\exists \bar{X} . t : T]] & = \exists \bar{X} \cdot [[t : T]] & provided \bar{X} # f t v (T) \\ [[(t : T) : T^{'}]] & = [[t : T]] \land T \leq T^{'} \end{aligned}

The effect of these rules is simple. The construct

\exists \bar{x}

.t is an indication to the constraint generator that the type variables

\bar{X}

, which may occur free within type annotations inside

t

, should be existentially bound at this point. The side-condition

\bar{X}

f t v (T)

ensures that quantifying over

\bar{X}

in the generated constraint does not capture type variables in the expected type T. It can always be satisfied by

α

-conversion of the expression

\exists \bar{X}

.t. The construct (

t : T

) is an indication to the constraint generator that the expression

t

should have type

T

, and it is treated as such by generating the subconstraint

[[t : T]]

. The expression's type may be an arbitrary supertype of

T

, hence the auxiliary constraint

T \leq T^{'}

1.9.29 EXAMPlE: In DM extended with pairs, the expression

λ z_{1} \cdot λ z_{2} \cdot \exists x . ((z_{1}

X), (z_{2} : X))

has most general type

\forall X . X \to X \to X \times X

. Indeed, the constraint generated for this expression contains the pattern

\exists x . ([[z_{1} : x]] \land [[z_{2} : x]] \land \dots)

, which causes

z_{1}

and

z_{2}

to receive the same type. Note that this style is more flexible than that employed in Example 1.9.28, where we were forced to use a single, monolithic type annotation to express this sharing constraint.

1.9.30 REMARK: In practice, a type variable is usually represented as a memory cell in the typechecker's heap. So, one cannot say that the source code contains type variables; rather, it contains names that are meant to stand for type variables. Let us write

X

for such a name, and

T

for a type made of type constructors and names, rather than of type constructors and type variables. Then, our new expression forms are really

\exists \bar{X}

.t and (

t : T

). When the constraint generator enters the scope of an introduction form

\exists \bar{X}

.t, it allocates a vector of fresh type variables

\bar{X}

, and augments an internal environment with the bindings

\bar{X} \mapsto \bar{X}

. Because the type variables are fresh, the side-condition of the first constraint generation rule above is automatically satisfied. When the constraint generator finds a type annotation (

t : T

), it looks up the internal environment to translate the type annotation

T

into an internal type

T

-which fails if

T

contains a name that is not in scope-and applies the second constraint generation rule above.

1.9.31 ExERcise

[⋆ ⋆, ↛]

: Let

\bar{X} \supseteq f t v (T)

and

\bar{X} # f t v (t)

. Check that the constraints

[[(t : \exists \bar{X} . T) : T^{'}]]

and

[[\exists \bar{X} . (t : T) : T^{'}]]

are equivalent. In other words, the local type annotations introduced earlier may be expressed in terms of the more complex constructs described above.

1.9.32 EXERCISE

[⋆ ⋆, ↛]

: One way of giving identity semantics to our new type annotation constructs is to erase them altogether prior to execution. Give an inductive definition of

⌊ t ⌋

, the expression obtained by removing all type annotation constructs from the expression

t

. Check that

[[t : T]]

entails

[[⌊ t ⌋

T]]

and explain why this is sufficient to ensure type soundness.

It is interesting to study how explicit introduction of existentially quantified type variables interacts with let-polymorphism. The source of their interaction lies in the difference between the constraints let

z : \forall \bar{x} [\exists X . C_{1}] . T

C_{2}

and

\exists

x.let

z : \forall \bar{x} [C_{1}] . T

C_{2}

, which was explained in Example 1.3.28. In the former constraint, every free occurrence of

z

inside

C_{2}

causes a copy of

\exists x . C_{1}

to be taken, thus creating its own fresh copy of X. In the latter constraint, on the other hand, every free occurrence of

z

inside

C_{2}

produces a copy of

C_{1}

. All such copies share references to

X

, because its quantifier was not duplicated. In the former case, one may say that the type scheme assigned to

z

is polymorphic with respect to

X

, while in the latter case it is monomorphic. As a result, the placement of type variable introduction expressions with respect to let bindings in the source code is meaningful: introducing a type variable outside of a let construct prevents it from being generalized.

1.9.33 ExAmple: In DM extended with integers and Booleans, the program let

f =

\exists X . λ z . (z : X)

in (f

0, f

true

)

is well-typed. Indeed, the type scheme assigned to

f

\forall X . X \to X

. However, the program

\exists X

.let

f = λ z . (z : X)

in (

f 0, f

true) is ill-typed. Indeed, the type scheme assigned to

f

X \to X

; then, no value of

X

satisfies the constraints associated with the applications

f 0

and

f

true. The latter behavior is observed in Objective Caml, where type variables are implicitly introduced at the outermost level of expressions:

More details about the treatment of type annotations in Standard ML, Objective Caml, and Haskell are given on page 113.

1.9.34 EXERcisE

[⋆, ↛]

: Determine which constraints are generated for the two programs in Example 1.9.33. Check that the former is indeed well-typed, while the latter is ill-typed.

Recursive types

We have shown that specializing

HM (X)

with an equality-only syntactic model yields

HM (=)

, a constraint-based formulation of Damas and Milner's type system. Similarly, it is possible to specialize

HM (X)

with an equalityonly free regular tree model, yielding a constraint-based type system that may be viewed as an extension of Damas and Milner's type discipline with recursive types. This flavor of recursive types is sometimes known as equirecursive, since cyclic equations, such as

X = X \to X

, are then satisfiable. Our theorems about type inference and type soundness, which are independent of the model, remain valid. The constraint solver described in Section 1.8 may be used in
the setting of an equality-only free regular tree model: the only difference with the syntactic case is that the occurs check is no longer performed.

Please note that, although ground types are regular, types remain finite objects: their syntax is unchanged. The

μ

notation commonly employed to describe recursive types may be emulated using type equations: for instance, the notation

μ X . X \to X

corresponds, in our constraint-based approach, to the type scheme

\forall x [X = X \to X]

X

Although recursive types come for free, as explained above, they have not been adopted in mainstream programming languages based on ML-the-typesystem. The reason is pragmatic: experience shows that many nonsensical expressions are well-typed in the presence of recursive types, whereas they are not in their absence. Thus, the gain in expressiveness is offset by the fact that many programming mistakes are detected later than otherwise possible. Consider, for instance, the following OCaml session:

This nonsensical variant of map is essentially useless, yet well-typed. Its principal type scheme, in our notation, is

\forall X Y Z [Y =

list

Y \land Z =

list

Z] . X \to Y \to Z

. In the absence of recursive types, it is ill-typed, since the constraint

Y =

list

Y \land Z =

list

Z

is then false.

The need for equirecursive types is usually suppressed by the presence of algebraic data types, which offer isorecursive types, in the language. Yet, they are still necessary in some situations, such as in Objective Caml's objectoriented extension (Rémy and Vouillon, 1998), where recursive object types are commonly inferred. In order to allow recursive object types while still rejecting the above variant of map, Objective Caml's constraint solver implements a selective occurs check, which forbids cycles unless they involve the type constructor

⟨ \cdot ⟩

associated with objects. The corresponding model is a tree model where every infinite path down a tree must encounter the type constructor

⟨ \cdot ⟩

infinitely often.

1.10 Universal quantification in constraints

The constraint logic studied so far allows a set of variables

\bar{X}

to be existentially quantified within a formula

C

. The resulting formula

\exists \bar{x}

C

receives its standard meaning: it requires

C

to hold for some

\bar{X}

. However, we currently have no way of requiring a formula

C

to hold for all

\bar{X}

. Is it possible to extend our
logic with universal quantification? If so, what are the new possibilities offered by this extension, in terms of type inference? The present section proposes some answers to these questions.

It is worth noting that, although the standard notation for type schemes involves the symbol

\forall

, type scheme introduction and instantiation constraints do not allow an encoding of universal quantification. Indeed, a universal quantifier in a type scheme is very much like an existential quantifier in a constraint: this is suggested, for instance, by Definition 1.3.3 and by C-LETEx.

Constraints

We extend the syntax of constraints as follows:

C ::= \dots ∣ \forall \bar{x} . C

Universally quantified variables are often referred to as rigid, while existentially quantified variables are known as flexible. The logical interpretation of constraints (Figure 1-5) is extended as follows:

\begin{matrix} \forall \vec{t} ϕ [\vec{x} \mapsto \vec{t}] ⊢ def Γ in C \\ (CM-ForALL) & \bar{x} # f t v (Γ) \\ ⊢ def Γ in \forall \bar{x} . C \end{matrix}

We let the reader check that none of the results established in Section 1.3 are affected by this addition. Furthermore, the extended constraint language enjoys the following properties.

1.10.1 Lemma:

\forall \bar{x} . C ⊩ C

. Conversely,

\bar{x} # ftv (C)

implies

C ⊩ \forall \bar{x} . C

1.10.2 Lemma:

\bar{X} # ftv (C_{2})

implies

\forall \bar{x} . (C_{1} \land C_{2}) \equiv (\forall \bar{x} . C_{1}) \land C_{2}

1.10.3 Lemma:

\forall \bar{X} . \forall \bar{Y} . C \equiv \forall \bar{X} \bar{Y} . C

1.10.4 Lemma: Let

\bar{x} # \bar{Y}

. Then,

\exists \bar{x} . \forall \bar{Y} . C

entails

\forall \bar{Y} . \exists \bar{X} . C

. Conversely, if

\exists \bar{Y} . C

determines

\bar{X}

, then

\forall \bar{Y} . \exists \bar{X} . C

entails

\exists \bar{X} . \forall \bar{Y} . C

Constraint solving

We briefly explain how to extend the constraint solver described in Section 1.8 with support for universal quantification. (Thus, we again assume an equalityonly free tree model.) Constraint solving in the presence of equations and of existential and universal quantifiers is known as unification under a mixed prefix. It is a particular case of the decision problem for the first-order theory of equality on trees; see e.g. (Comon and Lescanne, 1989). Extending our solver is straightforward: in fact, the treatment of universal quantifiers turns

\begin{aligned} S; U; \forall \bar{x} . C \to S [\forall \bar{x} . ◻]; U; C \\ if \bar{x} # f t v (U) \\ S [\forall \bar{X} . \exists \bar{Y} \bar{Z} . []]; U; true \to S [\exists \bar{Y} . \forall \bar{X} . \exists \bar{Z} . []]; U; true \\ if \bar{X} # \bar{Y} \land \exists \bar{X} \bar{Z} \cdot U determines \bar{Y} \\ S [\forall \bar{x} X . \exists \bar{Y} . []]; U; true \to false \\ if X \notin \bar{Y} \land X ≺_{U}^{⋆} Z \land Z \notin X \bar{Y} \\ S [\forall \bar{X} X . \exists \bar{Y} . ◻]; X = T = ϵ \land U; true \to false \\ if X \notin \bar{Y} \land T \notin V \\ S [\forall \bar{X} . \exists \bar{Y} . ◻]; U_{1} \land U_{2}; true \to S; U_{1}; true \\ if \bar{X} \bar{Y} # ftv (U_{1}) \land \exists \bar{Y} \cdot U_{2} \equiv true \end{aligned}

Figure 1-16: Solving universal constraints

out to be surprisingly analogous to that of let constraints. To begin, we extend the syntax of stacks with so-called universal frames:

S ::= \dots ∣ S [\forall \bar{x} . ◻]

Because existential quantifiers cannot, in general, be hoisted out of universal quantifiers, rules S-Ex-1 to S-Ex-4 now allow floating them up to the nearest enclosing let or universal frame, if any, or to the outermost level, otherwise. Thus, in our machine representation of stacks, where rules S-Ex-1 to S-Ex-4 are applied in an eager fashion, every universal frame carries a list of the type variables that are existentially bound immediately after it, and integer ranks count not only let frames, but also universal frames.

The solver's specification is extended with the rules in Figure 1-16. SSolve-All, a forward rule, discovers a universal constraint and enters it, creating a new universal frame to record its existence. S-ALLEx exploits Lemma 1.10.4 to hoist existential quantifiers out of the universal frame. It is analogous to S-LETALL, and its implementation may rely upon the same procedure (Exercise 1.8.8). The next two rules detect failure conditions. SALL-FAIL-1 states that the constraint

\forall X . \exists \bar{Y} . U

is false if the rigid variable

X

is directly or indirectly dominated by a free variable

Z

. Indeed, the value of

X

is then determined by that of

Z

-but a universally quantified variable ranges over all values, so this is a contradiction. In such a case,

X

is commonly said to escape its scope. S-ALL-FAIL-2 states that the same constraint is false if

X

is equated with a nonvariable term. Indeed, the value of

X

is then
partially determined, since its head constructor is known, which again contradicts its universal status. Last, S-POP-ALL splits the current unification constraint into two components

U_{1}

and

U_{2}

, where

U_{1}

is made up entirely of old variables and

U_{2}

constrains young variables only. This decomposition is analogous to that performed by S-POP-LET. Then, it is not difficult to check that

\forall \bar{X} . \exists \bar{Y}

(U_{1} \land U_{2})

is equivalent to

U_{1}

. So, the universal frame, as well as

U_{2}

, are discarded, and the solver proceeds by examining whatever remains on top of the stack

S

It is possible to further extend the treatment of universal frames with two rules analogous to S-COMPRESS and S-UNNAME. In practice, this improves the solver's efficiency, and makes it easier to share code between the treatment of let frames and that of universal frames.

It is interesting to remark that, as far as the underlying unification algorithm is concerned, there is no difference between existentially and universally quantified type variables. The algorithm solves whatever equations are presented to it, without inquiring about the status of their variables. Equations that lead to failure, because a rigid variable escapes its scope or is equated with a nonvariable term, are detected only when the universal frame is exited. A perhaps more common approach is to mark rigid variables as such, allowing the unification algorithm to signal failure as soon as one of the two error conditions is encountered. In this approach, a rigid variable may successfully unify only with itself or with flexible variables fresher than itself. It is often called a Skolem constructor in the literature (Läufer and Odersky, 1994; Shields and Peyton Jones, 2002). An interesting variant of this approach appears in Dowek, Hardin, Kirchner and Pfenning's treatment of (higher-order) unification

(1995; 1998)

, where flexible variables are represented as ordinary variables, while rigid variables are encoded using De Bruijn indices.

The properties of our constraint solver are preserved by this extension: it is possible to prove that Lemmas 1.8.9, 1.8.10, and 1.8.11 remain valid.

Type annotations, continued

In Section 1.9, we introduced the expression form (

t : \exists \bar{X} . T

), allowing an expression

t

to be annotated with a type

T

whose free variables

\bar{X}

are locally and existentially bound. It is now natural to introduce the symmetric expression form (

t : \forall \bar{X} . T

), where

T

has kind

⋆, \bar{X}

is bound within

T

, and

\bar{X}

contains

f t v (T)

, as before. Its constraint generation rule is as follows:

[[(t : \forall \bar{X} \cdot T) : T^{'}]] = \forall \bar{X} \cdot [[t : T]] \land \exists \bar{X} \cdot (T \leq T^{'}) provided \bar{X} # f t v (t, T^{'})

The first conjunct requires

t

to have type

T

for all values of

\bar{X}

. Here, the type variables

\bar{X}

are universally bound, as expected. The second conjunct requires

T^{'}

to be some instance of the universal annotation

\forall \bar{X}

.T. Since

T^{'}

is only a monotype, it seems difficult to think of another sensible way of constraining

T^{'}

. For this reason, the type variables

\bar{X}

are still existentially bound in the second conjunct. This makes the interpretation of the universal quantifier in type annotations a bit more complex than that of the existential quantifier. For instance, when subtyping is interpreted as equality, the constraint generation rule may be read: a valid type for (

t : \forall \bar{X} . T

) is of the form

T

, for some choice of the type variables

\bar{X}

, provided

t

has type

T

for all choices of

\bar{X}

We remark that (

t : \forall \bar{X} . T

) must be a new expression form: it cannot be encoded by adding new constants to the calculus-whereas (

t : \exists \bar{X} . T

) couldbecause none of the existing constraint generation rules produce universally quantified constraints. Like all type annotations, it has identity semantics.

What is the use of universal type annotations, compared with existential type annotations? When a type variable is existentially bound, the typechecker is free to assign it whatever value makes the program well-typed. As a result, the expressions

(λ z . z \hat{+} \hat{1} : \exists X . X \to X)

and

(λ z . z : \exists X . X \to X)

are both welltyped:

X

is assigned int in the former case, and remains undetermined in the latter. However, it is sometimes useful to be able to insist that an expression should be polymorphic. This effect is naturally achieved by using a universally bound type variable. Indeed,

(λ z \cdot z \hat{+} \hat{1} : \forall X . X \to X)

is ill-typed, because

\forall X . (X =

int) is false, while (

λ z \cdot z : \forall X . X \to X)

is well-typed.

1.10.5 EXERCISE

[⋆]

: Write down the constraints

\exists z \cdot [[(λ z \cdot z \hat{+} \hat{1} : \forall X . X \to X) : Z]]

and

\exists Z . [[(λ z . z : \forall X . X \to X) : z]]

, which tell whether these expressions are well-typed. Check that the former is false, while the latter is satisfiable.

A universal type annotation, as defined above, is nothing but a (closed) Damas-Milner type scheme. Thus, the new construct (

t : \forall \bar{X} . T

) gives us the ability to ensure that the expression

t

admits the type scheme

\forall \bar{X}

.T. This feature is exploited at the module level in ML-the-programming-language, where it is necessary to check that the inferred type for a module component

t

is more general than the type scheme

S

that appears in the module's signature. In our view, this process simply consists in ensuring that

(t : S)

is well-typed.

In Section 1.9, we have pointed out that local (that is, closed) type annotations offer limited expressiveness, because they cannot share type variables. To lift this limitation, we have introduced the expression forms

\exists \bar{X}

t

and (

t : T

). The former binds the type variables

\bar{X}

within

t

, making them available for use in type annotations, and instructs the constraint generator to existentially quantify them at this point. The latter requires

t

to have

T

. It is natural to proceed in the same manner in the case of universal type annotations. We now introduce the expression form

\forall \bar{X}

.t, which also binds

\bar{X}

within

t

, but comes
with a different constraint generation rule:

[[\forall \bar{x} . t : T]] = \forall \bar{X} \cdot \exists Z \cdot [[t : Z]] \land \exists \bar{X} \cdot [[t : T]] provided \bar{X} # f t v (T) \land Z \notin f t v (t)

This rule is a bit more complex than that associated with the expression form

\exists \bar{X}

.t. Again, this is due to the fact that we do not wish to overconstrain T. The first exercise below shows that a more naïve version of the rule does not yield the desired behavior. The second exercise shows that this version does. The third exercise clarifies an efficiency concern.

1.10.6 EXERCISE

[⋆]

: Assume that

[[\forall \bar{X} . t : T]]

is defined as

\forall \bar{X}

[[t : T]]

, provided

\bar{X} # ftv (T)

. Write down the constraint

[[\forall X . (λ z \cdot z : X \to X) : Z]]

. Can you describe its solutions? Does it have the intended meaning?

1.10.7 ExErcise

[⋆ ⋆]

: Let

\bar{x} \supseteq f t v (T)

and

\bar{x} # f t v (t)

. Check that the constraints

[[(t : \forall \bar{X} . T) : T^{'}]]

and

[[\forall \bar{X} . (t : T) : T^{'}]]

are equivalent. In other words, local universal type annotations may also be expressed in terms of the more complex constructs described above.

1.10.8 EXERCISE

[⋆ ⋆ ⋆ ⋆, ↛]

: The constraint generation rule that appears above compromises the linear time and space complexity of constraint generation, because it duplicates the term

t

. It is possible to avoid this problem, but this requires a slight generalization of the constraint language. Let us write let

x : \forall \underline{\underline{X}} \bar{Y} [C_{1}] . T

C_{2}

for

\forall \bar{X} . \exists \bar{Y} . C_{1} \land

def

x : \forall \bar{X} \bar{Y} [C_{1}] . T

C_{2}

. In this extended let form, the underlined variables

\bar{x}

are interpreted as rigid, instead of flexible, while checking that

C_{1}

is satisfiable. However, the type scheme associated with

x

is not affected. Check that the above constraint generation rule may now be written as follows:

[[\forall \bar{X} . t : T]] = let x : \forall \underline{x} z [[[t : Z]]] . Z in x ⪯ T provided Z \notin f t v (t)

Roughly speaking, the new rule forms a most general type scheme for

t

, ensures that the type variables

\bar{X}

are unconstrained in it, and checks that

T

is an instance of it. Furthermore, it does not duplicate t. To complete the exercise, extend the specification of the constraint solver (Figures 1-12 and 116), as well as its implementation, to deal with this extension of the constraint language.

To conclude, let us once again stress that, if

T

has free type variables, the effect of the type annotation (

t : T

) depends on how and where they are bound. The effect of how stems from the fact that binding a type variable universally, rather than existentially, leads to a stricter constraint. Indeed, we let the reader check that

[[\forall \bar{X} . t : T]]

entails

[[\exists \bar{X} . t : T]]

, while the converse
does not hold in general. The effect of where has been illustrated, in the case of existentially bound type variables, in Section 1.9. It is due, in that case, to the fact that let and

\exists

do not commute. In the case of universally bound type variables, it may be imputed to the fact that

\forall

and

\exists

do not commute. For instance,

λ z . \forall X . (z : x)

is ill-typed, because inside the

λ

-abstraction, the program variable

z

cannot be said to have every type. However,

\forall X . λ z . (z : X)

is well-typed, because the identity function does have type

X \to X

for every

X

1.10.9 EXERCISE

[⋆]

: Write down the constraints

\exists Z . [[λ z . \forall x . (z : x) : z]]

and

\exists Z . [[\forall x . λ z . (z : X) : Z]]

, which tell whether these expressions are well-typed. Is the former satisfiable? Is the latter?

In Standard ML and Objective Caml, the type variables that appear in type annotations are implicitly bound. That is, there is no syntax in the language for the constructs

\exists \bar{X}

t

and

\forall \bar{x}

.t. When a type annotation (

t : T

) contains a free type variable

X

, a fixed convention tells how and where

X

is bound. In Standard ML,

X

is universally bound at the nearest val binding that encloses all related occurrences of X (Milner, Tofte, and Harper, 1990). The 1997 revision of Standard ML (Milner, Tofte, Harper, and MacQueen, 1997b) slightly improves on this situation by allowing type variables to be explicitly introduced at val bindings. However, they still must be universally bound. In Objective Caml,

X

is existentially bound at the nearest enclosing toplevel let binding; this behavior seems to be presently undocumented. We argue that (i) allowing type variables to be implicitly introduced is confusing; and (ii) for expressiveness, both universal and existential quantifiers should be made available to programmers. Surprisingly, these language design and type inference issues seem to have received little attention in the literature, although they have most likely been "folklore" for a long time. Peyton Jones and Shields (2003) study these issues in the context of Haskell, and concur with (i). Concerning (ii), they seem to think that the language designer must choose between existential and universal type variable introduction formswhich they refer to as "type-sharing" and "type-lambda"-whereas we point out that they may and should coexist.

Polymorphic recursion

Example 1.2.10 explains how the letrec construct found in ML-theprogramming-language may be viewed as an application of the constant fix, wrapped inside a normal let construct. Exercise 1.9.6 shows that this gives rise to a somewhat restrictive constraint generation rule: generalization occurs only after the application of fix is typechecked. In other words, in letrec

f = λ

z.t

_{1}

t_{2}

, all occurrences of

f

within

t_{1}

must have the same
(monomorphic) type. This restriction is sometimes a nuisance, and seems unwarranted: if the function that is being defined is polymorphic, it should be possible to use it at different types even inside its own definition. Indeed, Mycroft (1984) extended Damas and Milner's type system with a more liberal treatment of recursion, commonly known as polymorphic recursion. The idea is to only request occurrences of

f

within

t_{1}

to have the same type scheme. Hence, they may have different types, all of which are instances of a common type scheme. It was later shown that well-typedness in Mycroft's extended type system is undecidable (Henglein, 1993; Kfoury, Tiuryn, and Urzyczyn, 1993). To work around this stumbling block, one solution is to use a semialgorithm, falling back to monomorphic recursion if it does not succeed or fail in reasonable time. Although such a solution might be appealing in the setting of an automated program analysis, it is less so in the setting of a programmer-visible type system, because it may become difficult to understand why a program is ill-typed. Thus, we describe a simpler solution, which consists in requiring the programmer to explicitly supply a type scheme for f. This is an instance of a mandatory type annotation.

To begin, we must change the status of fix, because if fix remains a constant, then

f

must remain

λ

-bound and cannot receive a polymorphic type scheme. We turn fix into a language construct, which binds a program variable

f

, and annotates it with a DM type scheme. The syntax of values and expressions is thus extended as follows:

Please note that

f

is bound within

λ

z.t. The operational semantics is extended as follows.

\begin{matrix} (R-FIX') & (f i x f : S . λ z . t) v ⟶ (let f = f i x f : S . λ z . t in λ z . t) v \end{matrix}

The type annotation

S

plays no essential role in the reduction; it is merely preserved. It is now possible to define letrec

f : S = λ z_{t} t_{1}

t_{2}

as syntactic sugar for let

f = f i x f : S . λ z . t_{1}

t_{2}

We now give a constraint generation rule for fix:

[[f i x f : S . λ z . t : T]] = let f : S in [[λ z . t : S]] \land S ⪯ T

The left-hand conjunct requires the function

λ z

.t to have type scheme

S

, under the assumption that

f

has type

S

. Thus, it is now possible for different occurrences of

f

within

t

to receive different types. If

S

\forall \bar{X}

T

, where

\bar{X} # f t v (t)

, then we write

[[t : S]]

for

\forall \bar{X}

[[t : T]]

. Indeed, checking the validity of a polymorphic type annotation-be it mandatory, as is the case here, or optional, as was previously the case-requires a universally quantified constraint. The right-hand conjunct merely constrains

T

to be an instance of

S

Given the definition of letrec

f : S = λ z \cdot t_{1}

t_{2}

as syntactic sugar, the above rule leads to the following derived constraint generation rule for letrec:

[[

letrec

f : S = λ

z.t

t_{1}

t_{2} : T]] =

let

f : S

([[λ z . t_{1} : S]] \land [[t_{2} : T]])

This rule is arguably quite natural. The program variable

f

is assigned the type scheme

S

throughout its scope, that is, both inside and outside of the function's definition. The function

λ

z.t

_{1}

must itself have type scheme

S

. Last,

t_{2}

must have type

T

, as in every let construct.

1.10.10 EXERCISE

[⋆ ⋆]

: Prove that the derived constraint generation rule above is indeed valid.

It is straightforward to prove that the extended language still enjoys subject reduction. The proof relies on the following lemma: if

t

has type scheme

S

, then every instance of

S

is also a valid type for

t

1.10.11 Lemma:

[[t : S]] \land S ⪯ T ⊩ [[t : T]]

1.10.12 Theorem [SubJect Reduction]: (R-Fix')

\subseteq (⊑)

The programming language Haskell (Hudak, Peyton Jones, Wadler, Boutel, Fairbairn, Fasel, Guzman, Hammond, Hughes, Johnsson, Kieburtz, Nikhil, Partain, and Peterson, 1992) offers polymorphic recursion. Interesting details about its typing rules may be found in (Jones, 1999).

It is worth pointing out that some restricted instances of type inference in the presence of polymorphic recursion are decidable. This is typically the case in certain program analyses, where a type derivation for the program is already available, and the goal is only to infer extra atomic annotations, such as binding time or strictness properties. Several papers that exploit this idea are (Dussart, Henglein, and Mossin, 1995a; Jensen, 1998; Rehof and Fähndrich, 2001).

Universal types

ML-the-type-system enforces a strict stratification between types and type schemes, or, in other words, allows only prenex universal quantifiers inside types. We have pointed out earlier that there is good reason to do so: type inference for ML-the-type-system is decidable, while type inference for System

F

, which has no such restriction, is undecidable. Yet, this restriction comes at a cost in expressiveness: it prevents higher-order functions from accepting polymorphic function arguments, and forbids storing polymorphic functions inside data structures. Fortunately, it is in fact possible to circumvent the problem by requiring the programmer to supply additional type information.

The approach that we are about to describe is reminiscent of the way algebraic data type definitions allow circumventing the problems associated with equirecursive types (Section 1.9). Because we do not wish to extend the syntax of types with universal types of the form

\forall \bar{Y}

.T, we instead allow universal type definitions, of the form

D \vec{X} \approx \forall \bar{Y} . T

where D still ranges over data types. If D has signature

\vec{κ} \Rightarrow ⋆

, then the type variables

\vec{X}

must have kind

\vec{κ}

. The type

T

must have kind

⋆

. The type variables

\bar{X}

and

\bar{Y}

are considered bound within

T

, and the definition must be closed, that is,

f t v (T) \subseteq \bar{X} \bar{Y}

must hold. Last, the variance of the type constructor D must match its definition - a requirement stated as follows:

1.10.13 Definition: Let

D \vec{X} \approx \forall \bar{Y}

T

and

D {\vec{X}}^{'} \approx \forall {\bar{Y}}^{'} \cdot T^{'}

be two

α

-equivalent instances of a single universal type definition, such that

\bar{Y} # ftv (T^{'})

and

{\bar{Y}}^{'} # ftv (T)

. Then,

D \vec{X} \leq D {\vec{X}}^{'} ⊩ \forall {\bar{Y}}^{'} . \exists \bar{Y} . T \leq T^{'}

must hold.

This requirement is analogous to that found in Definition 1.9.8. The idea is, if

D \vec{X}

and

D {\vec{X}}^{'}

are comparable, then their unfoldings

\forall \bar{Y}

T

and

\forall {\bar{Y}}^{'} \cdot T^{'}

should be comparable as well. The comparison between them is expressed by the constraint

\forall {\bar{Y}}^{'} . \exists \bar{Y} . T \leq T^{'}

, which may be read: every instance of

\forall {\bar{Y}}^{'} . T^{'}

is (a supertype of) an instance of

\forall \bar{Y}

.T. Again, when subtyping is interpreted as equality, the requirement of Definition 1.10 .13 is always satisfied; it becomes nontrivial only in the presence of true subtyping.

The effect of the universal type definition

D \vec{X} \approx \forall \bar{Y} . T

is to enrich the programming language with a new construct:

v ::= \dots ∣ {pack}_{D} v t ::= \dots ∣ {pack}_{D} t E ::= \dots ∣ {pack}_{D} E

and with a new unary destructor open

D_{D}

. Their operational semantics is as follows:

\begin{matrix} (R-OPEN-ALL) & {open}_{D} ({pack}_{D} v) \overset{δ}{\to} v \end{matrix}

Intuitively,

{pack}_{D}

and open

_{D}

are the two coercions that witness the isomorphism between

D \vec{X}

and

\forall \bar{Y}

.T. The value

{p a c k}_{D} v

behaves exactly like

v

, except it is marked, as a hint to the typechecker. As a result, the mark must be removed using open

D_{D}

before the value can be used.

What are the typing rules for pack

_{D}

and open

_{D}

? In System F, they would receive types

\forall \bar{X} . (\forall \bar{Y} . T) \to D \vec{X}

and

\forall \bar{X}

\vec{X} \to \forall \bar{Y}

.T, respectively. However, neither of these is a valid type scheme: both exhibit a universal quantifier under an arrow.

In the case of

{p a c k}_{D}

, which has been made a language construct rather than a constant, we work around the problem by embedding this universal
quantifier in the constraint generation rule:

[[{pack}_{D} t : T^{'}]] = \exists \bar{X} \cdot ([[t : \forall \bar{Y} \cdot T]] \land D \vec{X} \leq T^{'})

The rule implicitly requires that

\bar{X}

be fresh for the left-hand side and that

D \vec{X} \approx \forall \bar{Y}

T

be (an

α

-variant of) the definition of

D

. The left-hand conjunct requires

t

to have type scheme

\forall \bar{Y}

.T. The notation

[[t : S]]

was defined on page 114. The right-hand conjunct states that a valid type for

{p a c k}_{D} t

is (a supertype of) D

\vec{X}

We deal with open as follows. Provided

\bar{X} # \bar{Y}

, we extend the initial environment

Γ_{0}

with the binding open

D_{D} : \forall \bar{X} Y . D \vec{X} \to T

. We have simply hoisted the universal quantifier outside of the arrow - a valid isomorphism in System F.

The proof of the subject reduction theorem must be extended with the following new case:

1.10.14 Theorem [SUbJect Reduction]: (R-OPEn-AlL)

\subseteq (⊑)

Proof: We have

\begin{matrix} (6) & \begin{array}{ll} let Γ_{0} in [[{open}_{D} ({pack}_{D} v) : T_{0}]] \\ \equiv & let Γ_{0} in \exists Z . ({open}_{D} ⪯ Z \to T_{0} \land [[{pack}_{D} v : Z]]) \\ \equiv & let Γ_{0} in \exists Z \cdot (\exists {\bar{X}}^{'} {\bar{Y}}^{'} \cdot (D {\vec{X}}^{'} \to T^{'} \leq Z \to T_{0}) \land \exists \bar{X} \cdot ([[v : \forall \bar{Y} . T]] \land D \vec{X} \leq Z)) \\ \equiv & let Γ_{0} in \exists \bar{X} {\bar{X}}^{'} {\bar{Y}}^{'} \cdot ([[v : \forall \bar{Y} \cdot T]] \land D \vec{X} \leq D {\vec{X}}^{'} \land T^{'} \leq T_{0}) \\ ⊩ & let Γ_{0} in \exists \bar{X} {\bar{X}}^{'} {\bar{Y}}^{'} \cdot ([[v : \forall \bar{Y} \cdot T]] \land T \leq T^{'} \land T^{'} \leq T_{0}) \\ ⊩ & let Γ_{0} in \exists \bar{X} \bar{Y} {\bar{X}}^{'} {\bar{Y}}^{'} \cdot [[v : T_{0}]] \\ \equiv & let Γ_{0} in [[v : T_{0}]] \end{array} \end{matrix}

where (1) is by definition of constraint generation for applications and for constants;

Z

is fresh; (2) is by definition of constraint generation for pack

_{D}

and open

_{D}

, where

D \vec{X} \approx \forall \bar{Y}

T

and

D {\vec{X}}^{'} \approx \forall {\bar{Y}}^{'} . T^{'}

are two

α

-equivalent instances of the definition of

D; \bar{X}, \bar{Y}, {\bar{X}}^{'}

, and

{\bar{Y}}^{'}

are fresh and satisfy

\bar{Y} # f t v (T^{'})

and

{\bar{Y}}^{'} # ftv (T); (3)

is by C-ExAnd, C-Arrow, and C-ExTrans, which allows eliminating Z; (4) is by Definition 1.10.13, Lemma 1.10.1, and C-ExAnd; (5) is by Lemmas 1.10 .11 and

1.6 .3; (6)

is by C-Ex*.

The proof of

(R -

CONTEXT

) \subseteq (⊑)

must also be extended with a new subcase, corresponding the new production

E ::= \dots ∣ {pack}_{D} E

. If the language is pure, this is straightforward. In the presence of side effects, however, this subcase fails, because universal and existential quantifiers in constraints do not commute. The problem is then avoided by restricting pack

_{D}

to values, as in Definition 1.7.7.

This approach to extending ML-the-type-system with universal (or existential - see below) types has been studied in (Läufer and Odersky, 1994;

Rémy, 1994; Odersky and Läufer, 1996; Shields and Peyton Jones, 2002). Laüfer and Odersky have suggested combining universal or existential type declarations with algebraic data type definitions. This allows suppressing the cumbersome pack

D_{D}

and open

D_{D}

constructs; instead, one simply uses the standard syntax for constructing and deconstructing variants and records.

Existential types

Existential types (TAPL Chapter 24) are close cousins of universal types, and may be introduced into ML-the-type-system in the same manner. Actually, existential types have been introduced in ML-the-type-system before universal types. We give a brief description of this extension, insisting mainly on the differences with the case of universal types.

We now allow existential type definitions, of the form

D \vec{X} \approx \exists \bar{Y}

.T. The conditions required of a well-formed definition are unchanged, except the variance requirement, which is dual:

1.10.15 Definition: Let

D \vec{X} \approx \exists \bar{Y}

T

and

D {\vec{X}}^{'} \approx \exists {\bar{Y}}^{'} \cdot T^{'}

be two

α

-equivalent instances of a single existential type definition, such that

\bar{Y} # ftv (T^{'})

and

{\bar{Y}}^{'} # ftv (T)

. Then,

D \vec{X} \leq D {\vec{X}}^{'} ⊩ \forall \bar{Y} \cdot \exists {\bar{Y}}^{'} . T \leq T^{'}

must hold.

The effect of this existential type definition is to enrich the programming language with a new unary constructor pack

_{D}

and with a new construct:

t ::= \dots ∣

open

_{D} t t

and

E ::= \dots | {open}_{D} E t | {open}_{D} v E

. Their operational semantics is as follows:

\begin{matrix} (R-OPEN-Ex) & {open}_{D} ({pack}_{D} v_{1}) v_{2} ⟶ v_{2} v_{1} \end{matrix}

In the literature, the second argument of open

D_{D}

is often required to be a

λ

-abstraction

λ

z.t, so the construct becomes open

_{D} t (λ z . t)

, often written open

_{D} t

z

t

Provided

\bar{X} # \bar{Y}

, we extend the initial environment

Γ_{0}

with the binding pack

_{D} : \forall \bar{X} \bar{Y} . T \to D \vec{X}

. The constraint generation rule for open

_{D}

is as follows:

[[{open}_{D} t_{1} t_{2} : T^{'}]] = \exists \bar{X} . ([[t_{1} : D \vec{X}]] \land [[t_{2} : \forall \bar{Y} . T \to T^{'}]])

The rule implicitly requires that

\bar{X}

be fresh for the left-hand side, that

\bar{Y}

be fresh for

T^{'}

, and that

D \vec{X} \approx \forall \bar{Y} . T

be (an

α

-variant of) the definition of

D

. The left-hand conjunct simply requires

t_{1}

to have type

D \vec{X}

. The right-hand conjunct states that the function

t_{2}

must be prepared to accept an argument of type

T

, for any

\bar{Y}

, and produce a result of the expected type

T^{'}

. In other words,

t_{2}

must be a polymorphic function.

The type scheme of existential pack

_{D}

resembles that of universal open

D_{D}

, while the constraint generation rule for existential pen

_{D}

is a close cousin
of that for universal pack

D_{D}

. Thus, the duality between universal and existential types is rather strong. The main difference lies in the fact that the existential open

D_{D}

construct is binary, rather than unary, so as to limit the scope of the newly introduced type variables

\bar{Y}

. The duality may be better understood by studying the encoding of existential types in terms of universal types (Reynolds, 1983b).

As expected, R-OPEn-Ex preserves types.

1.10.16 Theorem [SubJect Reduction]: (R-OpEn-Ex)

\subseteq (⊑)

1.10.17 ExERcise

[⋆ ⋆, ↛]

: Prove Theorem 1.10.16. The proof is analogous, although not identical, to that of Theorem 1.10.14.

In the presence of side effects, the new production

E ::= \dots ∣

open

_{D}

E

is problematic. The standard workaround is to restrict the second argument to open

_{D}

to be a value.

1.11 Rows

In Section 1.9, we have shown how to extend ML-the-programming-language with algebraic data types, that is, variant and record type definitions, which we now refer to as simple. This mechanism has a severe limitation: two distinct definitions must define incompatible types. As a result, one cannot hope to write code that uniformly operates over variants or records of different shapes, because the type of such code is not even expressible.

For instance, it is impossible to express the type of the polymorphic record access operation, which retrieves the value stored at a particular field

ℓ

inside a record, regardless of which other fields are present. Indeed, if the label

ℓ

appears with type

T

in the definition of the simple record type

D \vec{X}

, then the associated record access operation has type

\forall \bar{X}

\vec{X} \to T

. If

ℓ

appears with type

T^{'}

in the definition of another simple record type, say

D^{'} {\vec{X}}^{'}

, then the associated record access operation has type

\forall {\bar{X}}^{'} . D^{'} {\vec{X}}^{'} \to T^{'}

; and so on. The most precise type scheme that subsumes all of these incomparable type schemes is

\forall X Y . X \to Y

. It is, however, not a sound type scheme for the record access operation. Another powerful operation whose type is currently not expressible is polymorphic record extension, which copies a record and stores a value at field

ℓ

in the copy, possibly creating the field if it did not previously exist, again regardless of which other fields are present. (If

ℓ

was known to previously exist, the operation is known as polymorphic record update.)

In order to assign types to polymorphic record operations, we must do away with record type definitions: we must replace named record types, such as D

\vec{X}

, with structural record types that provide a direct description of the record's
domain and contents. (Following the analogy between a record and a partial function from labels to values, we use the word domain to refer to the set of fields that are defined in a record.) For instance, a product type is structural: the type

T_{1} \times T_{2}

is the (undeclared) type of pairs whose first component has type

T_{1}

and whose second component has type

T_{2}

. Thus, we wish to design record types that behave very much like product types. In doing so, we face two orthogonal difficulties. First, as opposed to pairs, records may have different domains. Because the type system must statically ensure that no undefined field is accessed, information about a record's domain must be made part of its type. Second, because we suppress record type definitions, labels must now be predefined. However, for efficiency and modularity reasons, it is impossible to explicitly list every label in existence in every record type.

In what follows, we explain how to address the first difficulty in the simple setting of a finite set of labels. Then, we introduce rows, which allow dealing with an infinite set of labels, and address the second difficulty. We define the syntax and logical interpretation of rows, study the new constraint equivalence laws that arise in their presence, and extend the first-order unification algorithm with support for rows. Then, we review several applications of rows, including polymorphic operations on records, variants, and objects, and discuss alternatives to rows.

Records with finite carrier

Let us temporarily assume that

L

is finite. In fact, for the sake of definiteness, let us assume that

L

{ℓ_{a}, ℓ_{b}, ℓ_{c}}

To begin, let us consider only full records, whose domain is exactly

L

-in other words, tuples indexed by

L

. To describe them, it is natural to introduce a type constructor record of signature

⋆ \otimes ⋆ \otimes ⋆ \Rightarrow ⋆

. The type record

T_{a} T_{b} T_{c}

represents all records where the field

ℓ_{a}

(resp.

ℓ_{b}, ℓ_{c}

) contains a value of type

T_{a}

(resp.

T_{b}, T_{c}

). Please note that record is nothing but a product type constructor of arity 3 . The basic operations on records, namely creation of a record out of a default value, which is stored into every field, update of a particular field (say,

ℓ_{b}

), and access to a particular field (say,

ℓ_{b}

), may be assigned the following type schemes:

\begin{aligned} {\cdot} : & \forall X . X \to record X X X \\ {\cdot with ℓ_{b} = \cdot} : & \forall X_{a} X_{b} X_{b}^{'} X_{c} \cdot record X_{a} X_{b} X_{c} \to X_{b}^{'} \to record X_{a} X_{b}^{'} X_{c} \\ \cdot {ℓ_{b}} : & \forall X_{a} X_{b} X_{c} \cdot record X_{a} X_{b} X_{c} \to X_{b} \end{aligned}

Here, polymorphism allows updating or accessing a field without knowledge of the types of the other fields. This flexibility is made possible by the property that all record types are formed using a single record type constructor.

This is fine, but in general, the domain of a record is not necessarily

L

: it may be a subset of

L

. How may we deal with this fact, while maintaining the above key property? A naïve approach consists in encoding arbitrary records in terms of full records, using the standard algebraic data type option, whose definition is option

X \approx

pre

X +

abs. We use pre for present and abs for absent: indeed, a field that is defined with value

v

is encoded as a field with value pre

v

, while an undefined field is encoded as a field with value abs. Thus, an arbitrary record whose fields, if present, have types

T_{a}, T_{b}

, and

T_{c}

, respectively, may be encoded as a full record of type record (option

T_{a}

) (option

T_{b}

) (option

T_{c}

). This naive approach suffers from a serious drawback: record types still contain no domain information. As a result, field access must involve a dynamic check, so as to determine whether the desired field is present: in our encoding, this corresponds to the use of case option .

To avoid this overhead and increase programming safety, we must move this check from runtime to compile time. In other words, we must make the type system aware of the difference between pre and abs. To do so, we replace the definition of option by two separate algebraic data type definitions, namely pre

X \approx

pre

X

and abs

\approx

abs. In other words, we introduce a unary type constructor pre, whose only associated data constructor is pre, and a nullary type constructor abs, whose only associated data constructor is abs. Record types now contain domain information: for instance, a record of type record abs (pre

T_{b}

) (pre

T_{c}

) must have domain

{ℓ_{b}, ℓ_{c}}

. Thus, the type of a field tells whether it is defined. Since the type pre has no data constructors other than pre, the accessor pre

^{- 1}

, whose type is

\forall X

.pre

X \to X

, and which allows retrieving the value stored in a field, cannot fail. Thus, the dynamic check has been eliminated.

To complete the definition of our encoding, we now define operations on arbitrary records in terms of operations on full records. To distinguish between the two, we write the former with angle braces, instead of curly braces. The empty record \langle\rangle , where all fields are undefined, may be defined as

{

abs

}

. Extension at a particular field (say,

ℓ_{b}) ⟨ \cdot

with

ℓ_{b} = \cdot ⟩

is defined as

λ r . λ z . {r

with

ℓ_{b} =

pre

z}

. Access at a particular field (say,

ℓ_{b}) \cdot ⟨ ℓ_{b} ⟩

is defined as

λ

z.pre

^{- 1} z . {ℓ_{b}}

. It is straightforward to check that these operations have the following principal type schemes:

\begin{aligned} ⟨ ⟩ : & record abs abs abs \\ ⟨ \cdot with ℓ_{b} = \cdot ⟩ : & \forall X_{a} X_{b} X_{b}^{'} X_{c} \cdot record X_{a} X_{b} X_{c} \to X_{b}^{'} \to record X_{a} (pre X_{b}^{'}) X_{c} \\ \cdot ⟨ ℓ_{b} ⟩ : & \forall X_{a} X_{b} X_{c} .record X_{a} (pre X_{b}) X_{c} \to X_{b} \end{aligned}

It is important to notice that the type schemes associated with extension and access at

ℓ_{b}

are polymorphic in

X_{a}

and

X_{c}

, which now means that these operations are insensitive not only to the type, but also to the presence or
absence of the fields

ℓ_{a}

and

ℓ_{c}

. Furthermore, extension is polymorphic in

X_{b}

, which means that it is insensitive to the presence or absence of the field

ℓ_{b}

in its argument. The subterm pre

X_{b}^{'}

in its result type reflects the fact that

ℓ_{b}

is defined in the extended record. Conversely, the subterm pre

X_{b}

in the type of the access operation reflects the requirement that

ℓ_{b}

be defined in its argument.

Our encoding of arbitrary records in terms of full records was carried out for pedagogical purposes. In practice, no such encoding is necessary: the data constructors pre and abs have no machine representation, and the compiler is free to lay out records in memory in an efficient manner. The encoding is interesting, however, because it provides a natural way of introducing the type constructors pre and abs, which play an important role in our treatment of polymorphic record operations.

We remark that, in our encoding, the arguments of the type constructor record are expected to be either type variables or formed with pre or abs, while, conversely, the type constructors pre and abs are not intended to appear anywhere else. It is possible to enforce this invariant using kinds. In addition to

⋆

, let us introduce the kind

⋄

of field types. Then, let us adopt the following signatures: pre:

⋆ \Rightarrow ⋄

, abs :

⋄

, and record :

⋄ \otimes ⋄ \otimes ⋄ \Rightarrow ⋆

1.11.1 Exercise [

⋆

, Recommended,

\to

]: Check that the three type schemes given above are well-kinded. What is the kind of each type variable?

1.11.2 Exercise

[⋆ ⋆

, Recommended,

↛]

: Our record types contain information about every field, regardless of whether it is defined: we encode definedness information within the type of each field, using the type constructors pre and abs. A perhaps more natural approach would be to introduce a family of record type constructors, indexed by the subsets of

L

, so that the types of records with different domains are formed with different constructors. For instance, the empty record would have type {} ; a record that defines the field

ℓ_{a}

only would have a type of the form

{ℓ_{a} : T_{a}}

; a record that defines the fields

ℓ_{b}

and

ℓ_{c}

only would have a type of the form

{ℓ_{b} : T_{b}; ℓ_{c} : T_{c}}

; and so on. Assuming that the type discipline is Damas and Milner's (that is, assuming an equalityonly syntactic model), would it be possible to assign satisfactory type schemes to polymorphic record access and extension? Would it help to equip record types with a nontrivial subtyping relation?

Records with infinite carrier

Finite records are insufficient both from practical and theoretical points of view. In practice, the set of labels could become very large, making the type of every record as large as the set of labels itself, even if only a few labels are
actually defined. In principle, the set of labels could even be infinite. Actually, in modular programs the whole set of labels may not be known in advance, which amounts in some way to working with an infinite set of labels. Thus, records must be drawn from an infinite set of labels-whether their domains are finite or infinite. Still, we can restrict our attention to records that are almost constant, that is, records where only a finite number of fields differ. With this restriction, full records (defined everywhere) can always be built by giving explicit definitions for a finite number of fields and a default value for all other fields, as in the finite case. For instance, the record

{{{

false

}

with

ℓ = 1}

with

ℓ^{'} =

true

}

is the record equal to true on field

ℓ^{'}

, to 1 on field

ℓ

, and to false on any other field.

Types of records are functions from labels to types, called rows. However, for sake of generality, we use a unary type constructor, say

Π

, as an indirection between rows and record types. Moreover, we further restrict our attention to the case where rows are also almost constant. (The fact that the property holds for record values does not imply that it also holds for record types, for the default value of some record could have a polymorphic type, and one could wish to see each field with a different instance of this polymorphic type. So this is a true restriction, but a reasonable one.) Thus, rows can also be represented by giving explicit types for a finite number of fields and a default type for all other fields. We write

\partial T

the row whose type is

T

on every field, and

(ℓ : T; T^{'})

the row whose type is

T

on field

ℓ

and

T^{'}

on other fields. Formally,

\partial

is a unary type constructor and

ℓ

is a family of binary type constructors, written with syntactic sugar

(ℓ : \cdot; \cdot)

. For example,

Π (ℓ

: bool ;

(ℓ^{'}

: int ;

\partial

bool

))

is a record type that describes records whose field

ℓ

carries a value of type bool, field

ℓ^{'}

carries a value of type int, and all other fields carry values of type bool. In fact, this is a sound type for the record defined above. In fact, the type

Π (ℓ^{'}

: int ;

(ℓ

:bool ;

\partial

bool

))

should also be a sound type for this record, since the order in which fields are specified should not matter. We actually treat both types as equivalent. Furthermore, the row

(ℓ :

bool ;

\partial

bool

)

, which stands for bool on field

ℓ

and

\partial

bool everywhere else, must also be equivalent to

\partial

bool, which stands for bool everywhere.

A record type may also contain type variables. For instance, the record

λ z . {z}

that maps any value

v

to a record with the default value

v

has type

X \to Π (\partial x)

. Projections of this record on any field will return a value of the same type

X

. By comparison, the function that reads some field

ℓ

of its (record) argument has type

Π (ℓ : X; Y) \to X

: this says that the argument must be a record where field

ℓ

has type

X

and other fields may have any type. Variable

Y

is called a row variable, since it can be instantiated to any row. For instance, Y can be instantiated to

(ℓ^{'} :

int

; Y^{'})

and as a result this function can be applied to the record above. Conversely, the row

\partial x

, which is equal to

(ℓ^{'} : x; x)

, can
only be instantiated to rows of the form

\partial T

, which are equal to

(ℓ^{'} : T; T)

, that is, to constant rows.

Syntax of row types

Let

L

be a denumerable collection of labels. We write

ℓ . L

for

{ℓ} ⊎ L

, which implies

ℓ \notin L

. We first introduce kinds, so as to distinguish rows such as (

ℓ

: int ;

\partial

bool) from basic types, such as int or int

\to

int.

1.11.3 DEFINITION [Row KinDs]: Let row kinds be composed of a particular kind Type and the collection of kinds

Row (L)

where

L

ranges over finite subsets of

L

. We use letter

s

to range over row kinds.

Intuitively, a row of kind

Row (L)

is a function of domain

L ∖ L

to types. That is,

L

specifies the set of labels that the row must not define. For instance, the (basic) type

Π (ℓ

: int ;

x)

has kind Type, the row

(ℓ

: int ;

x)

has kind

Row (\emptyset)

provided

X

has kind

Row ({ℓ})

To remain abstract the definition of rows is parameterized by a signature

S_{0}

for building basic types and a signature

S_{1}

for building rows. From those two signatures, we then define a new signature

S

that completely specifies the set of types. However, the signature

S

must superimposed row kinds on top of the (basic) kinds of the two input signatures

S_{0}

and

S_{1}

. We use product signatures to enlighten this process. More precisely, we build a product signature from two signatures

K \Rightarrow κ

and

K^{'} \Rightarrow κ^{'}

with the following notations: we write

κ . κ^{'}

for the pair

(κ, κ^{'}); K . κ

for the mapping

(d \mapsto K (d) . κ)^{d \in dom (K)}; (K \Rightarrow κ) . κ^{'}

for the kind signature

K . κ \Rightarrow κ . κ^{'}

; and symmetrically, we write

κ . K^{'}

and

κ . (K^{'} \Rightarrow κ^{'})

. The signature

S

reuses the same input type constructors as

S_{0}

and

S_{1}

, but at different row kinds. We use superscripts to provide copies of type constructors at different kinds, and thus avoid overloading of kinds.

1.11.4 Definition [Row extension of a signature]: Let

S_{0}

and

S_{1}

be signatures where all symbols of

S_{1}

are unary. The row extension of

S_{0}

with

S_{1}

is the signature

S

defined as follows where

κ

ranges over basic kinds (those used in

S_{0}

and

S_{1}

) and

s

ranges over row kinds:

$F \in dom (S)$	Signature	Conditions
$G^{s}$	$(K \Rightarrow κ) . s$	$(G : K \Rightarrow κ) \in S_{0}$
$H$	K.Row $(\emptyset) \Rightarrow κ$ . Type	$(H : K \Rightarrow κ) \in S_{1}$
$\partial^{κ, L}$	$κ . ($ Type $\Rightarrow Row (L))$
$ℓ^{κ, L}$	$κ . ($ Type $\otimes Row (ℓ . L) \Rightarrow Row (L))$	$ℓ \notin L$

We usually write

ℓ^{κ, L} : t_{1}

;

t_{2}

instead of

ℓ^{κ, L} t_{1} t_{2}

and let this symbol be right-associative. We often drop the superscripts of type constructors since,
for any type expression

T

, superscripts can be unambiguously recovered from the kind of

T

1.11.5 EXAmple: Let us assume there is a single basic kind

⋆

and that

S_{1}

contain a unique type constructor

Π

(hence of kind

⋆ \Rightarrow ⋆

). An example of row type is

X_{0} \to Π (ℓ_{1} : G; (Y \to \partial x_{0}))

. With all superscripts annotations, this type is

X_{0} \to^{⋆, Type} Π (ℓ_{1}^{⋆, Row (\emptyset)} : G^{Type}; (Y \to^{⋆, Row ({ℓ_{1}})} \partial^{⋆, Row ({ℓ_{1}})} X_{0})) .

Intuitively, this is the type of a function that takes a value of type

X_{0}

and returns a record where field

ℓ_{1}

has type

G

and all other fields are functions that given a value of an arbitrary type would returns a value of (the same) type

X_{0}

. An instance of this type is

X_{0} \to Π (ℓ_{1} : G; ((ℓ_{2} : Y_{2}; Y^{'}) \to (ℓ_{2} : X_{0}; \partial X_{0})))

, obtained by instantiating row variable

Y

and by expanding the constant row

\partial X_{0}

. As shown below, this type is actually equivalent to

X_{0} \to Π (ℓ_{1} : G

;

ℓ_{2} : Y_{2} \to X_{0}; (Y^{'} \to \partial X_{0}))

, by distributivity of type constructor

\to

other type constructor

ℓ_{2}

. Please, note again the difference between

Y

, which is a row variable that can expand to different type variables on different labels, and

\partial X

, which is a constant row that expands to the same type variable

X

on all labels.

1.11.6 EXAMPLE [ ILL-KINDED EXPRESSION ]: Under the assumptions of the previous example, the expression

X \to Π (X)

is not a row type, since variable

X

cannot simultaneously be of row kind Type and

Row (\emptyset)

as required by its two occurrences, from left to right respectively. The expression

(ℓ : x; ℓ : X^{'}; x^{''})

is also ill-kinded, for the inner expression

(ℓ : X^{'}; X^{''})

of row kind

Row (L)

with

ℓ \notin L

cannot also have row kind

Row ({ℓ})

, as required by its occurrence in the whole expression. Indeed, row kinds prohibit multiple definitions of the same label, as well as using rows in place of basic types and conversely. Notice that

Π (Π (X))

is also ill-formed, since type constructors of

S_{1}

are not lifted to row kinds and thus cannot appear in rows, except under the type constructor

\partial

, hence as basic types.

1.11.7 EXERCISE

[⋆ ⋆ ⋆, ↛]

: Design an algorithm that infers superscripts of type constructors of a type expression from its kind. Can the kind of the expression be inferred as well? Can you give an algorithm to check that type expressions are well-kinded when both the superscripts of type constructors and the kinds of the whole type expressions are omitted?

Meaning of rows

As mentioned above, a row of kind

Row (L)

stands for a function from

L ∖ L

to types. Actually, it is simpler to represent this function explicitly as an
infinitely branching tree in the model. For this purpose, we use a collection of constructors

L

of (infinite but denumerable) arity

L ∖ L

1.11.8 Definition [Row model]: Let

S

be the row extension of a signature

S_{0}

with a signature

S_{1}

. Let

S_{M}

be the following signature, where

κ

ranges over basic kinds and

L

ranges over finite subsets of

L

$F \in dom (S_{M})$	Signature	Conditions
$G$	$(K \Rightarrow κ)$ . Type	$(G : K \Rightarrow κ) \in S_{0}$
$H$	K.Row $(\emptyset) \Rightarrow κ$ . Type	$(H : K \Rightarrow κ) \in S_{1}$
$L^{κ}$	$κ . ($ Type $L ∖ L \Rightarrow Row (L))$

Let

M_{κ}

consist of the regular trees

t

built over the signature

S_{M}

such that

t (ϵ)

has image kind

κ

. We interpret a type constructor

F

of signature

K \Rightarrow κ . s

as a function that maps

T \in M_{K}

t \in M_{κ . s}

defined by cases on

F

and on the basic kind

κ

$F \in S$	$t (ϵ)$	For $d \in dom (K)$ and $ℓ \in L ∖ L, ℓ \neq ℓ_{0}$ .
$G^{Type}$	$G$	$t / d = T (d)$
$H$	$H$	$t / 1 = T (1)$
$G^{Row (L)}$	$L^{κ}$	$t (ℓ) = G \land t / (ℓ \cdot d) = T (d) / ℓ$
$\partial^{κ, L}$	$L^{κ}$	$t / ℓ = T (1)$
$ℓ_{0}^{κ, L}$	$L^{κ}$	$t / ℓ_{0} = T (1) \land t / ℓ = T (2) / ℓ$

In the presence of subtyping, we let type constructors

G

and

H

behave in

S_{M}

as in

S_{0}

and

S_{1}

and type constructors

L^{κ}

be isolated and covariant in every position. Models that define ground types and interpret type constructors in this manner are referred to as row models.

Reasoning with row types

In this section, we assume a subtyping model. All reasoning principles also apply to the equality-only model, which is a subcase of the subtyping model.

The meaning of rows has been carefully defined so as to be independent of some syntactical choices. In particular, the order in which the types of significant fields have been declared leaves the meaning of rows unchanged. This is formally stated by the following Lemma.

1.11.9 Lemma: The equations of Figure 1-17 are equivalent to true.

Proof: Each equation can be considered independently. It suffices to see that any ground assignment

ϕ

sends both sides of the equation to the same element

\begin{aligned} (C-Row-LL) & (ℓ_{1} : T_{1}; ℓ_{2} : T_{2}; T_{3}) & = (ℓ_{2} : T_{2}; ℓ_{1} : T_{1}; T_{3}) \\ (C-Row-DL) & \partial T & = (ℓ : T; \partial T) \\ (C-Row-DG) & \partial (G T_{1} \dots T_{n}) & = G \partial T_{1} \dots \partial T_{n} \\ (C-Row-GL) & G (ℓ : T_{1}; T_{1}^{'}) \dots (ℓ : T_{n}; T_{n}^{'}) & = (ℓ : G T_{1} \dots T_{n}; G T_{1}^{'} \dots T_{n}^{'}) \end{aligned}

Figure 1-17: Equational reasoning for row types.

\begin{aligned} (ℓ_{1} : T_{1}; T_{1}^{'}) = (ℓ_{2} : T_{2}; T_{2}^{'}) \equiv \exists X \cdot (T_{1}^{'} = (ℓ_{2} : T_{2}; X) \land T_{2}^{'} = (ℓ_{1} : T_{1}; x)) \\ if X # ftv (T_{1}, T_{1}^{'}, T_{2}, T_{2}^{'}) \land ℓ_{1} \neq ℓ_{2} \\ (ℓ : T; T^{'}) = G T_{i}^{I} \equiv \exists {(x_{i}, X_{i}^{'})}^{I} \cdot (T = G X_{i}^{I} \land T^{'} = G X_{i}^{'} \land T_{i} = (ℓ : x_{i}; X_{i}^{'})) \\ if {(X_{i}, X_{i})}^{I} # f t v (T, T^{'}, T_{i}^{I}) \\ (C-MuTE-LG) \\ \partial T = G T_{i}^{I} \equiv \exists x_{i}^{I} \cdot (T = G x_{i}^{I} \land {(T_{i} = \partial x_{i})}^{I}) \\ if X_{i}^{I} # ftv (T, T_{i}^{I}) \\ \partial T = (ℓ : T^{'}; T^{''}) \equiv T = T^{'} \land \partial T = T^{''} \end{aligned}

Figure 1-18: Constraint equivalence laws for rows.

in the model, which follows directly from the meaning of row types. Notice that this fact only depends on the semantics of types and not on the semantics of the subtyping predicate.

It follows from those equations that type constructors

ℓ, \partial

, and

G

are never isolated, each equation exhibiting a pair of compatible top symbols. Variances and incompatible pairs of type constructors depend on the signature

S_{0} ⊎ S_{1}

. However, it is not difficult to see that type constructors

\partial

and

ℓ

are logically covariant in all directions and that the logical variance of types constructors

G

dom (S_{0} ⊎ S_{1})

correspond to their syntactic variance, which, in most cases, will allow the decomposition of equations with the same top symbols. Moreover, an equation between two terms whose top symbols form one of the four compatible pairs derived from the equations of Figure 1-17 holds only if immediate subexpressions can be "conciliated" in some way. There is a transformation quite similar to decomposition, called mutation, that mimics the equations for rows (Figure 1-17) and described by the rules of Figure 1-18. For sake of readability and conciseness, we write

T_{i}^{I}

instead of

T_{i}^{i \in I}

1.11.10 Lemma [Mutation]: All equivalence laws in Figure 1-18 hold.

Proof:

Case C-Mute-LL: Let X # ftv( $T_{1}, T_{1}^{'}, T_{2}, T_{2}^{'}) (1)$ and $ℓ_{1} \neq ℓ_{2}$ . Let $Row (L)$ be the row kind of this equation. Let $ϕ$ be a ground assignment that validates the constraint $(ℓ_{1} : T_{1}; T_{1}^{'}) = (ℓ_{2} : T_{2}; T_{2}^{'})$ . That is, $ϕ$ sends all terms of the multi-equation to the same ground type $t$ of row kind $Row (L)$ . Moreover, the row-term semantics implies that $t$ satisfies $t (ϵ) = L, t / ℓ_{1} = ϕ (T_{1}) =$ $ϕ (T_{2}^{'}) / ℓ_{1}, t / ℓ_{2} = ϕ (T_{1}^{'}) / ℓ_{2} = ϕ (T_{2})$ , and $t / ℓ = ϕ (T_{2}^{'}) / ℓ = ϕ (T_{1}^{'}) / ℓ$ for all $ℓ \in L ∖ ℓ_{1} \cdot ℓ_{2} . L$ (2). Let $t^{'}$ be the tree defined by $t^{'} (ϵ) = ℓ_{1} \cdot ℓ_{2} . L$ and $t^{'} / ℓ = t / ℓ$ for all $ℓ \in L ∖ ℓ_{1} \cdot ℓ_{2} . L$ . By construction and (2), $ϕ [X \mapsto t^{'}]$ satisfies both equations $T_{1}^{'} = (ℓ_{2} : T_{2}; x)$ and $T_{2}^{'} = (ℓ_{1} : T_{1}; x)$ . Thus by CM-ExisTs and (1), $ϕ$ satisfies $\exists X \cdot T_{1}^{'} = (ℓ_{2} : T_{2}; X) \land T_{2}^{'} = (ℓ_{1} : T_{1}; X)$ . Conversely, we have the entailment:

\begin{aligned} \exists X . (T_{1}^{'} = (ℓ_{2} : T_{2}; X) \land T_{2}^{'} = (ℓ_{1} : T_{1}; X)) \\ \equiv \exists X . ((ℓ_{1} : T_{1}; T_{1}^{'}) = (ℓ_{1} : T_{1}; ℓ_{2} : T_{2}; X) \land \\ (3) & (ℓ_{2} : T_{2}; T_{2}^{'}) = (ℓ_{2} : T_{2}; ℓ_{1} : T_{1}; X)) \\ (4) & ⊩ \exists X . (ℓ_{1} : T_{1}; T_{1}^{'}) = (ℓ_{2} : T_{2}; T_{2}^{'}) \\ (5) & \equiv (ℓ_{1} : T_{1}; T_{1}^{'}) = (ℓ_{2} : T_{2}; T_{2}^{'}) \end{aligned}

(3) follows by covariance of

ℓ_{1}

and

ℓ_{2}

; (4) by C-Row-LL and transitivity of equivalence; (5) by

C - E x *

and (1).

Cases C-Mute-LG, C-Mute-DG, and C-Mute-DL: The reasoning is similar to the case C-Mute-LL.

Solving row constraints in an equality model

In this section, we extend the constraint solver for the equality-only free tree model (Figure 1-11), so as to handle rows. We thus assume an equality-only model.

Mutation is a common technique to solve equations in a large class of nonfree algebras that are described by syntactic theories (Kirchner and Klay, 1990). The equations of Figure 1-17 happen to be a syntactic presentation of an equational theory, from which a unification algorithm could be automatically derived (Rémy, 1993). We recover the same transformation rules directly, without using results on syntactic theories.

The following lemma shows that all pairs of distinct type constructors for which there is no mutation rule are in fact incompatible.

1.11.11 Lemma: All symbols

H \in S_{1}

are isolated. Furthermore for every pair of distinct type constructors

G_{1}, G_{2} \in dom (S_{0} ⊎ S_{1})

, and every row kind

s

, we have

G_{1}^{s} ⋈ G_{2}^{s}

Proof: Terms of the form

H \vec{T}

are interpreted by ground types with

H

at occurrence

ϵ

, and conversely the only interpretations of types with

H

at occurrence

ϵ

are terms of the form

H \vec{T}

. Hence, no ground assignment can ever

\begin{aligned} (ℓ_{1} : X_{1}; X_{1}^{'}) = (ℓ_{2} : T_{2}; T_{2}^{'}) = ϵ \to \exists Y . (X_{1}^{'} = (ℓ_{2} : T_{2}; Y) \land T_{2}^{'} = (ℓ_{1} : X_{1}; Y)) \\ \land (ℓ_{1} : X_{1}; X_{1}^{'}) = ϵ \\ if Y # ftv (X_{1}, X_{1}^{'}, T_{2}, T_{2}^{'}) \land ℓ_{1} \neq ℓ_{2} \\ (ℓ : X; X^{'}) = G T_{i}^{i \in I} = ϵ \to \exists {(Y_{i}, Y_{i}^{'})}^{i \in I} \cdot (X = G Y_{i}^{i \in I} \land X^{'} = G Y_{i}^{'}_{i}^{i \in I} \land T_{i} = (ℓ : Y_{i}; Y_{i}^{'})) \\ \land (ℓ : X; X^{'}) = ϵ \\ if {(Y_{i}, Y_{i}^{'})}^{i \in I} # f t v (X, X^{'}, T_{i}^{i \in I}) \\ \partial X = G T_{i}^{i \in I} = ϵ \to \exists Y_{i}^{i \in I} \cdot (X = G Y_{i}^{i \in I} \land {(T_{i} = \partial Y_{i})}^{i \in I}) \\ \land \partial x = ϵ \\ if Y_{i}^{i \in I} # f t v (X, T_{i}^{i \in I}) \\ \partial x = (ℓ : T; T^{'}) = ϵ \to X = T \land \partial x = T^{'} \land \partial x = ϵ \\ G \vec{T} = G^{'} {\vec{T}}^{'} = ϵ \to false \\ if F ⋈ F^{'} \end{aligned}

Figure 1-19: Unification addendum for row types

send

H \vec{T}

and

F \vec{T^{'}}

to the same ground term when

F \neq H

and, as a result,

H

is isolated.

Let

G_{1}

and

G_{2}

be two type constructors of

S_{0}

. For

s =

Type, the interpretations of terms of the form

G_{1}^{s} \vec{T}

and

G_{2}^{s} {\vec{T}}^{'}

are ground types with symbols

G_{1}

and

G_{2}

at occurrence

ϵ

, respectively. Hence they cannot be made equal under any ground assignment. For

s = Row (L)

, the interpretations of terms of the form

G_{1}^{s} \vec{T}

and

G_{2}^{s} {\vec{T}}^{'}

are ground types with constructor

L

at occurrence

ϵ

and constructors

G_{1}

and

G_{2}

at occurrence 1, respectively. Hence they cannot be made equal under any ground assignment.

Any other combination of type constructors forms a compatible pair, as illustrated by equations of Figure 1-17 and can be transformed by mutation rules of Figure 1-18. The constraint solver for row-terms is the relation

\to^{†}

defined by the rewriting rules of Figure 1-11, except Rule S-CLASH, which is replaced by the set of rules of Figure 1-19.

1.11.12 Lemma: The rewriting system

\to^{†}

is strongly normalizing.

Please, note that the termination of

\to^{†}

relies on types being well-kinded. In particular,

\to^{†}

would not terminate on the ill-kinded system of equations

X = ℓ : T; X^{'} \land X^{'} = ℓ^{'} : T; X

1.11.13 Lemma: If

U \to^{†} U^{'}

, then

U \equiv U^{'}

Proof: It suffices to check the property independently for each rule defining

\to^{†}

. The proof for rules of Figure 1-11 but S-CLASH remain valid for row terms. For S-Decompose, it follows by the invariance of all type constructors, which is preserved for row terms. For rule S-CLASS-I it follows by Lemma 1.11.11 and for mutation rules, it follows by Lemma 1.11.10.

Although reductions

\to

are not sound for row types, hence

\to

cannot be used for computation over row types, it has some interest. In particular, the following property shows that normal forms for row types are identical to normal forms for regular types.

1.11.14 Lemma: A system

U

in normal form for

\to^{†}

is also in normal form for

\to

Proof: The only rule of

\to

that is not in

\to^{†}

is S-CLASH. Thus, it suffices to observe that if Rule S-CLASH would be applicable, then either Rule S-CLASS-I or a mutation rule would be applicable as well.

As a corollary, Lemma 1.8.6 extends to row types.

Operations on records

We now illustrate the use of rows for typechecking operations on records. The simplest application of rows are full records with infinite carrier. Records types are expressed with rows instead of a simple product type. The basic operations are the same as in the finite case, that is, creation, polymorphic update, and polymorphic access, but labels are now taken from an infinite set. However, creation and polymorphic update, which where destructors are now taken as constructors and used to represent records as association lists. The access of a record

v

at a field

ℓ

is obtained by linearly searching

v

for a definition of field

ℓ

and returning this definition, or returning the default value if no definition has been found for

ℓ

1.11.15 Example [Full Records]: We assume a unique basic kind

⋆

and a unique covariant isolated type constructor

Π

S_{1}

. Let

{\cdot}

be a unary constructor,

({\cdot with \cdot = ℓ})^{ℓ \in L}

a collection of binary constructors, and

(ℓ . {\cdot})^{ℓ \in L}

a collection of unary destructors with the following reduction rules:

\begin{aligned} {v} \cdot {ℓ} & \overset{δ}{\to} & v \\ {w with ℓ = v} \cdot {ℓ} & \overset{δ}{\to} & v \\ {w with ℓ^{'} = v} \cdot {ℓ} \\ w . {ℓ} & if ℓ \neq ℓ^{'} & (RD-DEFAULT) \\ (RD-FOLLOw) \end{aligned}

Let the initial environment

Γ_{0}

contain the following bindings

\begin{aligned} {\cdot} : & \forall X . X \to Π (\partial X) \\ {\cdot with ℓ = \cdot} : & \forall X X Y . Π (ℓ : X; Y) \to X^{'} \to Π (ℓ : X^{'}; Y) \\ \cdot {ℓ} : & \forall X Y . Π (ℓ : X; Y) \to X \end{aligned}

1.11.16 ExERcise [Full Records,

⋆ ⋆ ⋆, ↛]

: Check that these definitions meet the requirements of Definition 1.7.6.

1.11.17 ExErcise [Field Exchange,

⋆ ⋆

]: Add an operation to permute two fields of a record: give the reduction rules and the typing assumptions and check that the requirements of Definition 1.7.6 are preserved.

1.11.18 ExErcise [Normal forms For Records,

⋆ ⋆ ⋆ ⋆

]: Record values may contain repetitions. For instance,

{{w

with

ℓ = v}

with

ℓ = v^{'}}

is a value that is in fact observationally equivalent to

{w

with

ℓ = v^{'}}

. So are the two record values

{{w

with

ℓ = v}

with

ℓ^{'} = v^{'}}

and

{{w

with

ℓ^{'} = v^{'}}

with

ℓ = v}

when

ℓ^{'} \neq ℓ

. Modify the semantics, so that two record values of the same type have similar structure and records do not contain inaccessible values.

1.11.19 ExERcise [Map Apply,

⋆ ⋆

]: Add a binary operation map such that the expressions (map v

w

{ℓ}

and v.

{ℓ}

{ℓ}

reduce to the same value for every label

ℓ

1.11.20 EXERCISE

[⋆, ↛]

: So far, full records are almost constants. This condition is not necessary for values, but only for types. As an example, introduce a primitive record, that is a nullary record constructor, that maps every label to a distinct integer. Give its typing assumption and review the semantics of records.

As opposed to full records, standard records are partial and their domains are finite (but with infinite carrier) and statically determined from their types. Standard records can be built by extending the empty record on a finite number of fields. We refer to such records as records with polymorphic extension. Record with polymorphic extension can be obtained by means of encoding into full records, much as in the finite case.

1.11.21 Example [Encoding of POLymorphic eXtension]: Reusing the two type definitions abs and pre that have introduced for the finite case, we let abs encodes an undefined field and prev encode a field with value v. We use the following syntactic sugar with their meaning and principal types:

\begin{aligned} ⟨ ⟩ \overset{def}{=} {a b s} \\ : Π (\partial a b s) \\ ⟨ \cdot with ℓ = \cdot ⟩ \overset{def}{=} λ v \cdot λ w \cdot {w with ℓ = pre v} \\ : \forall {X X}^{'} Y . Π (ℓ : X; Y) \to X^{'} \to Π (ℓ : pre X^{'}; Y) \\ \cdot ⟨ ℓ ⟩ \overset{def}{=} λ v \cdot {p r e}^{- 1} (v \cdot {ℓ}) \\ : \forall X Y . Π (ℓ : pre X; Y) \to X \end{aligned}

1.11.22 ExERcise [Recommended,

⋆

]: Extension may actually override an existing field. Can you define a version polymorphic extension that prevents this situation from happening? Add an operation that hide some particular field of a record.

Extensible records can also be implemented directly, without encoding into full records. In fact, this requires only a tiny variation on full records.

1.11.23 EXample [Records With Polymorphic eXtension]: Let

⋆

and

⋄

be two basic kinds. Let the basic signature

S_{0}

contain (in addition to

\to

) the covariant isolated type constructors pre of kind

⋆ \Rightarrow ⋄

and abs of kind

⋄

. In the presence of subtyping, we may assume pre

⩽

abs. Let

S_{1}

contain the unique covariant isolated type constructor

Π

of kind

⋄ \Rightarrow ⋆

. Let \langle\rangle be a unary constructor,

({\cdot with \cdot = ℓ)^{ℓ \in L}

be a binary constructor, and

(ℓ . {\cdot})^{ℓ \in L}

be a unary destructor with the following reduction rules:

\begin{aligned} ⟨ w with ℓ = v ⟩ . ⟨ ℓ ⟩ \overset{δ}{\to} v (ER-FOUnd) \\ ⟨ w with ℓ^{'} = v ⟩ . ⟨ ℓ ⟩ \overset{δ}{\to} w. {ℓ} if ℓ \neq ℓ^{'} (ER-FOLLOw) \end{aligned}

Let

Γ_{0}

contain the following typing assumptions:

\begin{aligned} ⟨ ⟩ : & Π (\partial a b s) \\ ⟨ \cdot with ℓ = \cdot ⟩ & \forall X X Y . Π (ℓ : X; Y) \to X^{'} \to Π (ℓ : pre X^{'}; Y) \\ \cdot ⟨ ℓ ⟩ : & \forall X Y . Π (ℓ : pre X; Y) \to X \end{aligned}

Notice that the typing assumptions obtained from the direct approach are identical to those obtained via the encoding into full records in Example 1.11.21.

1.11.24 EXERCISE

[⋆ ⋆ ⋆ ⋆, ↛]

: Prove the equivalence between the direct semantics and the semantics via the encoding into records with a default.

1.11.25 Exercise [Recommended,

⋆ ⋆, ↛

]: Prove that type soundness for extensible records hold in both the subtyping model and equality-only models.

1.11.26 Exercise [Recommended,

⋆, ↛

]: Check that in the subtyping a record with more fields can be used in place of records with fewer fields. Check that this is not the case in the equality-only model.

1.11.27 EXAMPLE [REFINEMENT OF RECORD TYPES]: In an equality-only model, records with more fields cannot be used in place of records with fewer fields. However, this may be partially recovered by a small refinement of the structure of types. The presence of fields can actually be split form their types, thus enabling some polymorphism over the presence of fields while type of fields themselves remains fixed. Let o be a new basic kind. Let type constructors abs and pre be both of kind

\circ

and let

\cdot

be a new type constructor of kind

\circ \otimes ⋆ \Rightarrow ⋄

. Let

Γ_{0}

contain the following typing assumptions:

\begin{aligned} ⟨ ⟩ : & \forall X . Π (\partial (abs \cdot X)) \\ ⟨ \cdot with ℓ = \cdot ⟩ : & \forall {Z X X}^{'} Y . Π (ℓ : X; Y) \to X^{'} \to Π (ℓ : Z \cdot X^{'}; Y) \\ \cdot ⟨ ℓ ⟩ : & \forall X Y . Π (ℓ : pre \cdot X; Y) \to X \end{aligned}

The semantics of records remain unchanged. The new signature strictly generalizes the previous one (strictly more programs can be typed) while preserving type soundness. Here is a program that can now be typed and that could not be typed before:

(if a then ⟨ ⟨ ⟨ ⟩ with ℓ^{'} = true) with ℓ = 1 ⟩ else ⟨ ⟨ ⟩ with ℓ = 2 ⟩). ⟨ ℓ ⟩

Notice however, that when a present field is forgotten, the type of the field is not. Therefore two records defining the same field but with incompatible types can still not be mixed, which is possible in the subtyping model.

1.11.28 EXAmple [REFINED SUbTypIng]: The previous refinement for an equalityonly model is not much interesting in the case of a subtyping model.

The subtyping assumption pre

⩽

abs makes abs play the role of

T

for fields. That is, abs encodes the absence of information and not the information of absence. In other words, a value whose field

ℓ

has type abs may either be undefined or defined on field

ℓ

; in the latter case, the fact that field

ℓ

is actually defined has just been forgotten. Thus, types only provides a lower approximation of the actual domain of records. This is a lost of accuracy by comparison with the equality-only model, where a record domain is known from its type. As a result, some optimizations in the representation of records that are only possible when the exact domain of a record is statically known are lost.

Fortunately, there is a way to recover such accuracy. A conservative solution could of course to drop the inequality pre

⩽

abs. Notice that this would still be more expressive than using an equality model since, for instance

Π (ℓ

: pre

(T_{1} \to T_{2}); T) \leq Π (ℓ

: pre

⊤; T)

would still hold, as long as

\to\leq ⊤

does hold. This solution is known as depth-only subtyping for records, while the previous one provided both depth and width record subtyping. Conversely, one could also keep width subtyping and disallow depth subtyping, by preserving
the relation pre

⩽

abs while requiring pre to be invariant; in this case, presence of fields can be forgotten as a whole, but the types of fields cannot be weakened as long as fields remain visible.

Another more interesting solution consists in introducing another type constructor either of signature

⋄

and assuming that pre

⩽

either and abs

⩽

either (but pre

≮

abs). Here, either plays the role of

T

for fields and means either present (and forgotten) or absent. while abs really means absent. The accuracy of typechecking can be formally stated as the fact that a record value of type

Π (ℓ

: abs

; T)

cannot define field

ℓ

1.11.29 Example [miXed subtyping]: It is tempting to mix all variations of Example 1.11.28 together. As a first attempt, we may assume that the basic signature

S_{0}

contains covariant type constructors pre and maybe and invariant type constructors pre

_{=}

and maybe

=

, all of kind

⋆ \Rightarrow ⋄

and two type constructors abs and either of kind

⋄

, and that the subtype ordering

⩽

is defined by the following diagram:

Intuitively, we wish that pre

=

and maybe

=

be logically invariant, pre and maybe be logically covariant, and the equivalences pre

= T \leq

maybe

_{=} T^{'} \equiv T = T^{'}

and

\begin{matrix} (1) & pre = T \leq pre T^{'} \equiv pre T \leq maybe T^{'} \equiv {maybe}_{=} T \leq maybe T^{'} \equiv T \leq T^{'} \end{matrix}

simultaneously hold. However, (1) requires, for instance, type constructors pre

=

and pre to have the same direction, which is not currently possible since they do not have the same variance. Interestingly, this restriction may be relaxed by assigning variances of directions on a per type constructor basis and define structural subtyping accordingly (See Exercise 1.11.30). Then, replacing all occurrences of pre by pre

=

Γ_{0}

preserves type soundness and allows for both accurate record types and flexible subtyping in the same setting.

1.11.30 ExERcise [RELaXed variances,

⋆ ⋆ ⋆, ↛]

: Let

\emptyset

be allowed as a new variance, let extend the composition of variances defined in Example 1.3.9 with

ν \emptyset = \emptyset

, and let

⩽ \emptyset

stands for the full relation on type constructors. Let each type constructor

F

of signature

K \Rightarrow κ

now come with a mapping

ϑ (F)

from

dom (K)

to variances. Let

ϑ (t, t^{'}, π)

be the variance of two
ground types

t

and

t^{'}

at a path

π

recursively defined by

ϑ (t, t^{'}, d \cdot π) =

(ϑ (t (ϵ)) (d) \cap ϑ (t^{'} (ϵ)) (d)) ϑ (t / d, t^{'} / d, π)

and

ϑ (t, t^{'}, ϵ) = +

. Then define the interpretation of subtyping as follows: if

t, t^{'} \in M_{κ}

, let

t \leq t^{'}

hold if and only if for all path

π \in dom (t) \cap dom (t^{'}), t (π) ⩽^{ϑ (t, t^{'}, π)} t^{'} (π)

holds.

Check that the relation

\leq

remains a partial ordering. Check that a type constructor whose direction

d

has been syntactically declared covariant (respectively contravariant, invariant) is still logically covariant (respectively contravariant, invariant) in

d

Record concatenation

Record concatenation takes two records and combines them into a new record whose fields are taken from whatever argument defines them. Of course, there is an ambiguity when the two records do not have disjoint domains and a choice should be made to disambiguate such cases. Symmetric concatenation let concatenation be undefined in this case (Harper and Pierce, 1991), while asymmetric concatenation let one-side (usually the right side) always take priority. Despite a rather simple semantics, record concatenation remains hard to type (with either a strict or a priority semantics). Solutions to type inference for record concatenation may be found, for instance, in (Wand, 1989; Rémy, 1992; Pottier, 2000).

Polymorphic variants

Variants can be defined via algebraic data-type definitions. However, as fields for records, variant tags are taken from a relatively small, finite collection of labels and two variant definitions will have incompatible types. Thus, to remain compatible, two variants must chose their tag among a larger collection that is a superset of all the possible tags of either variant. In general, this reduces the accuracy of types and forces useless dynamic checks for tags that could otherwise be known not to occur. Extensible variants (page 93) allow to work with an arbitrary large collection of tags, but do not improve accuracy. Polymorphic variants refers to a more precise typechecking mechanism for variants, where types more accurately describes the tags that may actually occur. They allow to build values of sum types out of a large, potentially infinite predefined set of tags and call polymorphic functions to explore them. As for record, this problem could be tackled by first considering polymorphic operations over variants built from a finite set of tags and total variants with an infinite set of tag independently and then by combining both approaches together. We propose a direct solution by a simple analogy with records.

Indeed, type constructor pre can be used to distinguish a (finite) set of tags
that the variant may actually carry, from other tags that are certain not to occur and typed with abs. For example, a variant

ℓ

.v, built from a value

v

with a constructor tag

ℓ

of arity one. may be assigned the principal type scheme

\forall X . Σ (ℓ :

pre

T; X)

where

T

is the type of

v

. The unary type constructor

Σ

is used to coerce rows to variant types-thus, variant types and record types may share the same inner row structure and be simply distinguished by their top symbol. An instance of this polymorphic type is

\forall X . Σ (ℓ

:pre

T

; abs

)

, which tells that the variant must have been built with tag

ℓ

and no other tag, thus retaining exact information about the shape of the value. Another instance of the variant polymorphic type is

Σ (ℓ :

pre

T; ℓ^{'} :

pre

T^{'}

; abs

)

. Indeed, it is sound to assume that the value might also have been built with some other

tag ℓ^{'}

, even if we know that this is not actually the case. Interestingly, both values

ℓ

.v and

ℓ^{'}

.v have this type and can be mixed at this type.

We use filters to explore variants. A filter

[ℓ : v ∣ v^{'}]

is a function that expects a variant argument, thus of the form

ℓ^{'}

.w. It then proceeds with either

v w

, if

ℓ^{'} = ℓ

, or

v^{'} w

otherwise. The type of this filter is

Σ (ℓ :

pre

T; T^{'}) \to T^{''}

where

T

is the type of values accepted by

v, Σ (ℓ : T^{'''}; T^{'})

is the type of values accepted by

v^{'}

, and

T^{''}

is the type of values returned by both

v

and

v^{'}

. Any type

T^{'''}

would do, including, in particular, abs. Indeed, when w is passed to

v^{'}

, it is known not to have tag

ℓ

, so the behavior of

v^{'}

ℓ

does not matter. The null filter [] can be used for

v^{'}

. This filter should actually never be applied, which we ensure by assigning

◻

the type

\forall X . Σ (\partial a b s) \to X

, for no variant value has type

Σ (\partial a b s)

. For instance, the filter

[ℓ : v_{ℓ} ∣ [ℓ^{'} : v_{ℓ^{'}} ∣ []]]

, which may be abbreviated as

[ℓ : v_{ℓ} ∣ ℓ^{'} : v_{ℓ^{'}}]

can be applied to either

ℓ

.v or

ℓ^{'} . v^{'}

. The following example formalizes polymorphic variants.

1.11.31 Example [Polymorphic variants]: Let

⋆

and

⋄

be two basic kinds. Let

S

contain in addition to the arrow type constructor the two type constructors pre of kind

⋆ \Rightarrow ⋄

and abs of kind

⋄

. In the presence of subtyping we may assume abs

⩽

pre. Let

S_{1}

contain the unique covariant isolated type constructor

Σ

of kind

⋄ \Rightarrow ⋆

. Let

Γ_{0}

be composed of unary constructors

(ℓ . \cdot)^{ℓ \in L}

and primitives [ of arity 0 and

([ℓ : \cdot ∣ \cdot] \cdot)^{ℓ \in L}

of arity 3 , given with the following reduction rules:

\begin{aligned} [ℓ : v ∣ v^{'}] ℓ . w \overset{δ}{\to} v w \\ [ℓ : v ∣ v^{'}] ℓ^{'} . w \overset{δ}{\to} v^{'} w if ℓ \neq ℓ^{'} \end{aligned}

and contain the following typing assumptions:

\begin{aligned} ℓ . \cdot : & \forall X Y . X \to Σ (ℓ : pre X; Y) \\ [] : & \forall X . Σ (\partial a b s) \to X \\ [ℓ : \cdot ∣ \cdot] : & \forall {X X}^{'} Y Y Y^{'} . (X \to Y) \to (Σ (ℓ : X^{'}; Y^{'}) \to Y) \to Σ (ℓ : pre X; Y^{'}) \to Y \end{aligned}

1.11.32 ExERcise [Soundness for Extensible Variants,

⋆ ⋆ ⋆ ⋆, ↛

]: Prove type soundness for extensible variants in both equality-only and subtyping models.

Other applications of rows

Polymorphic records and variants are the most well-known applications of rows. Besides the many variations on their presentations - we have only illustrated some of them-there are several other interesting applications of rows.

Since objects can be viewed as record-of-functions, at least from a typing point of view, rows can also be used to type structural objects (Wand, 1994; Rémy, 1994; Rémy and Vouillon, 1998) and provide, in particular, polymorphic method invocation. This is the key to typechecking objects in Objective Caml (Rémy and Vouillon, 1998). First-class messages (Nishimura, 1998; Müller and Nishimura, 1998; Pottier, 2000) combine records and variants in an interesting way: while filters over variant types enforce all branches to have the same return type, first-class messages treat filters as records of functions (also called objects) rather than functions from a variant type to a shared return type. A message is an element of a variant type. The application of an object to a message, that is of a record of functions to a variant type, selects from the record the branch labeled with the same tag as the message and applies it to the content of the message, much as pattern matching. However, these applications are typechecked more accurately by first restricting the domain of the record to the set of tags that the message may possibly carry, and thus other branches and in particular their return type are left unconstrained.

Row types may also represent set of properties within types or type refinements and be used in type systems for program analysis. Two examples worth mentioning are their application to soft-typing (Cartwright and Fagan, 1991; Wright and Cartwright, 1994) and typechecking of uncaught exceptions (Leroy and Pessaux, 2000).

The key to rows is to decompose the set of row labels into a class of finite partitions that is closed by some operations. Here, those partitions are composed of singleton labels and co-finite sets of labels; the operations are merging (or conversely splitting) a singleton label and a co-finite set of labels. Other decompositions are possible, for instance, one could imagine to consider labels in a two-dimensional space. More generally, labels might also be given internal structure, for instance, one might consider automatons as labels. Notice also that record types are stratified, since rows, that is, expressions of kind

Row (L)

, may not themselves contain records - constructors of

S_{1}

are only given the image row kind Type. This restriction can be partially
relaxed leading to rows of increasing degrees (Rémy, 1992b) ... and complexity! Yet more intriguing are typed-indexed rows where labels are themselves types (Shields and Meijer, 2001).

Alternatives to rows

The original idea of using rows to describe types of extensible records is due to Wand (Wand, 1987, 1988). A key simplification to row types is to make them total functions from labels to types and encode definiteness explicitly in the structure of fields, for instance with pre and abs type constructors, as presented here. This decomposition reduces the resolution of unification constraints to a simple equational reasoning (Rémy, 1993, 1992a). Other approaches that do not treat rows as total functions seem more

a d

hoc and have often hard-wired restrictions (Jategaonkar and Mitchell, 1988; Ohori and Buneman, 1989; Berthomieu, 1993; Ohori, 1999). Among these partial solutions, (Ohori, 1999) is quite interesting for its overall simplicity in the case where polymorphic access alone is required. Rows and fields may also be represented within ad-hoc type constraints rather than terms and equality (or subtyping) constraints. For example, qualified types use the predicates (

T

has

ℓ : T^{'}

) and (

T

lacks

ℓ

) to mean that field

ℓ

of row

T

is defined with type

T^{'}

or undefined, respectively (Jones, 1994b; Odersky, Sulzmann, and Wehr, 1999b). These constraints are in fact equivalent in our equality-model to

\exists X . T = (ℓ

:pre

T^{'}; X)

and

\exists X . T = (ℓ :

abs

; X)

, respectively. Record typechecking has also been widely studied in the presence of subtyping. Usually, record subtyping is given meaning directly and not via rows. While these solutions are quite expressive, thanks to subtyping, they still suffer from their nonstructural treatment of record types and cannot type row extension. Thus, even in subtyping models the use of rows increases expressiveness, and is usually a simplification as well. The subtyping model can then also take advantage of the possibility of enriching type constructors pre and abs with more structure and relate them via subtyping (Pottier, 2000). Notice, that even though rows have been introduced for type inference, they seem to be beneficial to explicitly typed languages as well since even other advanced solutions (Cardelli and Mitchell, 1991; Cardelli, 1992) are limited.

Rules of Figure 1-19 are one way of solving row type constraints. In a model with subtyping constraints, a more direct closure-based resolution may be more appropriate (Pottier, 2003).

B Solutions to Selected Exercises

1.2.6 Solution: The definition does not behave as expected, because if is a destructor, whose arguments-according to the call-by-value semantics of MLthe-calculus-are evaluated before R-TRUE or R-FALSE is allowed to fire. As a result, the semantics of the expression if

t_{0}

then

t_{1}

else

t_{2}

is to evaluate both

t_{1}

and

t_{2}

before choosing one of them. Since these expressions may have side effects (for instance, they may fail to terminate, or update a reference), this semantics is undesirable. The desired evaluation order can be obtained by placing

t_{1}

and

t_{2}

within closures, which delays their evaluation, then invoking the closure returned by the conditional, forcing its body to be evaluated. In other words, the expression if

t_{0}

then

t_{1}

else

t_{2}

should now be viewed as syntactic sugar for if

t_{0} (λ

z.t

_{1}) (λ z . t_{2}) \hat{0}

. The choice of the constant

\hat{0}

is arbitrary, since it is discarded; any value would do.

1.2.21 Solution: Within Damas and Milner's type system, we have:

Please note that, because

X

occurs free within the environment

z_{1} : X

, it is impossible to apply DM-GEN to the judgement

z_{1} : X ⊢ z_{1} : X

in a nontrivial way. For this reason,

z_{2}

cannot receive the type scheme

\forall x

.X, and the whole expression cannot receive type

X \to Y

, where

X

and

Y

are distinct.

1.2.22 Solution: It is straightforward to prove that the identity function has type int

\to

int:

\frac{\bar{Γ_{0}; z : int ⊢ z : int}}{Γ_{0} ⊢ λ z . z : int \to int} DM-ABS

In fact, nothing in this type derivation depends on the choice of int as the type of

z

. Thus, we may just as well use a type variable

X

instead. Furthermore, after forming the arrow type

X \to X

, we may employ DM-GEN to quantify universally over

X

, since it no longer appears in the environment.

It is worth noting that, although the type derivation employs an arbitrary type variable

X

, the final typing judgement has no free type variables. It is
thus independent of the choice of

x

. In the following, we refer to the above type derivation as

Δ_{0}

Next, we prove that the successor function has type int

\to

int under the initial environment

Γ_{0}

. We write

Γ_{1}

for

Γ_{0}; z

: int, and make uses of DM-VAR implicit.

In the following, we refer to the above type derivation as

Δ_{1}

. We may now build a derivation for the third typing judgement. We write

Γ_{2}

for

Γ_{0}; f

: int

\to

int.

\frac{Δ_{1} \frac{Γ_{2} ⊢ f : int \to int Γ_{2} ⊢ \hat{2} : int}{Γ_{2} ⊢ f \hat{2} : int}}{Γ_{0} ⊢ let f = λ z \cdot z \hat{+} \hat{1} in f \hat{2} : int} DM-LET

To derive the fourth typing judgement, we re-use

Δ_{0}

, which proves that the identity function has polymorphic type. We write

Γ_{3}

for

Γ_{0}; f : \forall X . X \to X

. By DM-VAR and DM-INST, we have

Γ_{3} ⊢ f : (

int

\to

int

) \to (

int

\to

int) and

Γ_{3} ⊢ f :

int

\to

int. Thus, we may build the following derivation:

\begin{aligned} Γ_{3} ⊢ f : (int \to int) \to (int \to int) \end{aligned}

The first and third judgements are valid in the simply-typed

λ

-calculus, because they use neither DM-GEN nor DM-INST, and use DM-LET only to introduce the monomorphic binding

f :

int

\to

int into the environment. The second judgement, of course, is not: because it involves a nontrivial type scheme, it is not even a well-formed judgement in the simply-typed

λ

-calculus. The fourth judgement is well-formed, but not derivable, in the simply-typed

λ

-calculus. This is because

f

is used at two incompatible types, namely (int

\to

int)

\to

(int

\to

int) and int

\to

int, inside the expression

f f \hat{2}

. Both of these types are instances of

\forall X . X \to X

, the type scheme assigned to

f

in the environment

Γ_{3}

By inspection of DM-VAR, DM-GEN, and DM-INST, it is straightforward to see that, if

Γ_{0} ⊢ \hat{1} : T

is derivable, then

T

must be int. Since int is not an arrow type, the application

\hat{1} \hat{2}

cannot be well-typed under

Γ_{0}

. In fact, because this expression is stuck, it cannot be well-typed in a sound type system.

The expression

λ f

(f f)

is ill-typed in the simply-typed

λ

-calculus, because no type

T

may coincide with a type of the form

T \to T^{'}

. Indeed,

T

would then be a subterm of itself. For the same reason, this expression is ill-typed in

D M

as well. Indeed, it is not difficult to check that the presence of DM-GEN and DM-INST makes no difference: DM-GEN cannot generalize

T

as long as the binding

f : T

appears in the environment, and DM-INST can only instantiate

T

T

itself. Thus, the self-application

f f

is well-typed in DM only if

f

is let-bound, as opposed to

λ

-bound. The argument crucially relies on the fact that

f

must be assigned a monotype. Indeed, the expression

λ f . (f f)

is well-typed in an implicitly-typed variant of System F: one of its types is

(\forall X . X \to X) \to (\forall X . X \to X)

. It also relies on the fact that types are finite: indeed, this expression is well-typed in an extension of the simply-typed

λ

calculus with recursive types, where the equation

T = T \to T^{'}

has a solution.

1.2.23 Solution: It is clear that the effect of DM-GEN may be obtained by a series of successive applications of DM-GEN'. Conversely, consider an instance of DM-GEN', whose premises are

Γ ⊢ t : S (1)

and

X \notin f t v (Γ)

(2). Let us write

S = \forall \bar{X} . T

, where

\bar{X} # f t v (Γ)

(3). Applying DM-Inst to (1) and to the identity substitution yields

Γ ⊢ t : T

(4). Applying DM-GEN to (4), (2) and (3) yields

Γ ⊢ t : \forall x \bar{x} . T

, that is,

Γ ⊢ t : \forall X

.S. Thus, the effect of DM-GEN' may be obtained by DM-INST and DM-GEN.

It is clear that DM-INST is a particular case of DM-INST' where

\bar{Y}

is empty. Conversely, consider an instance of DM-INST', whose premises are

Γ ⊢ t

\forall \bar{X}

.T (1) and

\bar{Y} # ftv (\forall \bar{X}

. T) (2). Let

ρ

be a renaming that exchanges

\bar{Y}

with

\bar{Z}

, where

\bar{Z} # ftv (\forall \bar{Y} . [\vec{X} \mapsto \vec{T}] T)

(3) and

\bar{Z} # ftv (Γ)

(4). Applying DM-InsT to (1) yields

Γ ⊢ t : [\vec{X} \mapsto ρ \vec{T}] T

(5). Applying DM-GEN to (5) and (4) yields

Γ ⊢

t : \forall \bar{Z} \cdot [\vec{X} \mapsto ρ \vec{T}] T

, that is,

Γ ⊢ t : \forall ρ \bar{Y} . [\vec{X} \mapsto ρ \vec{T}] T

(6). Now, by (2) and (3), we have

[\vec{X} \mapsto ρ \vec{T}] T = ρ ([\vec{X} \mapsto \vec{T}] T)

, so (6) may be written

Γ ⊢ t : \forall ρ \bar{Y} . ρ ([\vec{X} \mapsto \vec{T}] T)

, that is,

Γ ⊢ t : ρ (\forall \bar{Y} . [\vec{X} \mapsto \vec{T}] T) (7)

. By (3), this is exactly

Γ ⊢ t : \forall \vec{Y} \cdot [\vec{X} \mapsto \vec{T}] T

. Thus, the effect of DM-INST' may be obtained by DM-INST and DM-GEN.

1.4.4 Solution: Let us recall that a program

t

is well-typed if and only if a judgement of the form

C, Γ ⊢ t : σ

, where

C

is satisfiable, holds. Let us show that it is in fact possible, without loss of generality, to require

σ

to be a monotype.

Assume

C, Γ ⊢ t : σ (1)

is derivable within

HM (X)

. Let us write

σ =

\forall \bar{X} [D]

.T, where

\bar{X} # f t v (C)

(2). Applying Lemma 1.4.1 to (1) yields

C ⊩

\exists \bar{X} . D

(3). By hm-Inst, (1) implies

C \land D, Γ ⊢ t : T

(4). By (3), we have

C \equiv C \land \exists \bar{x} . D \equiv \exists \bar{X} . (C \land D)

. Because

C

is satisfiable, this implies that

C \land D

is satisfiable as well. Thus, the judgement (4), which involves the monotype

T

, witnesses that

t

is well-typed.

We have shown that a program

t

is well-typed if and only if a judgement of the form

C, Γ ⊢ t : T

, where

C

is satisfiable, holds. Thus, by Theorems ?? and ??, well-typedness is the same for both rule sets.

1.4.5 Solution: By Theorem ??, every rule in Figure 1-8 is admissible in

HM (X)

. Of course, so is HM-GEN. So, every judgement that is derivable via the rules of Figure 1-8 and

H M - G E N

is a valid

HM (X)

judgement.

Conversely, assume

C, Γ ⊢ t : σ

(1) holds in

HM (X)

. We must show that it is derivable via the rules of Figure 1-8 and HM-GEN. Let us write

σ =

\forall \bar{x} [D]

.T, where

\bar{x} # f t v (C, Γ)

(2). By HM-Inst and (1), the judgement

C \land

D, Γ ⊢ t : T

(3) holds in

HM (X)

. This judgement involves a monotype, so, by Theorem ??, it is derivable via the rules of Figure 1-8. Furthermore, from (3) and (2), HM-GEN allows deriving

C \land \exists σ, Γ ⊢ t : σ

(4). Applying Lemma 1.4.1 to (1) yields

C ⊩ \exists σ

, so the judgement (4) may be written

C, Γ ⊢ t : σ

. We have shown that (1) is derivable via the rules of Figure 1-8 and HM-GEN. In fact, it is possible to apply HM-GEN only once, at the end of the derivation.

1.5.1 Solution: Within the type system

PCB (X)

, we have

The type variable

z

, which occurs free in the left-hand instance of VAR, is generalized. However,

z_{2}

does not receive the type scheme

\forall Z . Z

, which, as suggested earlier, is unsound; instead, it receives the constrained type scheme

\forall z [z_{1} ⪯ z] . z

. The latter is more restrictive than the former: indeed, the former claims that

z_{2}

has every type, while the latter only claims that every valid type for

z_{1}

is also a valid type for

z_{2}

. Let us now examine the constraint let

z_{1}

X; z_{2} : \forall Z [z_{1} ⪯ Z] . Z

z_{2} ⪯ Y

, which appears at the root of the derivation. By C-INID and C-IN*, it is equivalent to let

z_{1} : X

\exists Z . (z_{1} ⪯ Z \land Z \leq Y)

and to

\exists Z

X \leq Z \land Z \leq Y

), which by

C

-ExTRans is equivalent to

X \leq Y

. Thus, the judgement at the root of the above derivation may be written

X \leq

Y ⊢ λ z_{1}

. let

z_{2} = z_{1}

z_{2} : X \to Y

. In other words, the expression let

z_{2} =

z_{1}

z_{2}

has type

X \to Y

only under the assumption that

X

is a subtype of

Y

, which is sound. Even though LET allows unrestricted generalization of type variables, it remains sound, because the type scheme that it produces typically has free program identifiers, such as

\forall Z [z_{1} ⪯ Z] . Z

above.

1.7.10 Solution: Let

E =

let

z = E_{1}

t_{1}

and

E_{1} [t] / μ ⊑ E_{1} [t^{'}] / μ^{'}

(1). Then,

\begin{aligned} let Γ_{0}; ref M in [[E [t] / μ : T / M]] \\ (2) & = & let Γ_{0}; ref M in ((let z : \forall x [[[E_{1} [t] : x]]] . X in [[t_{1} : T]]) \land [[μ : M]]) \\ (3) & \equiv & let Γ_{0}; ref M; z : \forall x [[[E_{1} [t] / μ : X / M]]] . X in [[t_{1} : T]] \\ (4) & \equiv & let Γ_{0}; ref M; z : \forall x [let Γ_{0}; ref M in [[E_{1} [t] / μ : x / M]]] . X in [[t_{1} : T]] \\ (5) & ⊩ & let Γ_{0}; ref M; z : \forall x \bar{Y} [let Γ_{0}; ref M^{'} in [[E_{1} [t^{'}] / μ^{'} : x / M^{'}]]] . X in [[t_{1} : T]] \end{aligned}

where (2) is by definition of constraint generation, where

X \notin ftv (T, M) (6); (3)

is by (6), C-LETAND, and by definition of constraint generation; (4) is by (6) and C-LetDup; (5) follows from (1) and C-LETEx, for some

\bar{Y}

and

M^{'}

such that

\bar{Y} # ftv (X, M) (7)

and

f t v (M^{'}) \subseteq \bar{Y} \cup f t v (M)

(8) and

dom (M^{'}) = dom (μ^{'})

and

M^{'}

extends

M

. Note that (6), (7) and (8) imply

X \notin f t v (M^{'})

(9).

At this point, the type variables

\bar{Y}

, which determine the types of the newly allocated store cells, are universally quantified in the type scheme assigned to

z

, which is undesirable. We are stuck, because we cannot in general apply C-LETALL to hoist

\exists \bar{Y}

out of the let constraint. Let us now assume that, by some external means, we are guaranteed

\bar{Y} = \emptyset (10)

. Then, we may proceed as follows:

\begin{aligned} (11) & \equiv let Γ_{0}; ref M^{'}; z : \forall X [let Γ_{0}; ref M^{'} in [[E_{1} [t^{'}] / μ^{'} : X / M^{'}]]] . X in [[t_{1} : T]] \\ (12) & \equiv let Γ_{0}; ref M^{'} in [[E [t^{'}] / μ^{'} : T / M^{'}]] \end{aligned}

where (11) follows from the fact the the memory locations that appear free in

[[t_{1} : T]]

are members of

dom (μ)

, thus are not members of

dom (M^{'}) ∖ dom (M)

; (12) is obtained by performing the steps that lead to (4) in reverse.

The requirement that

\bar{Y}

be empty, that is,

f t v (M) = f t v (M^{'})

, is classic (Tofte, 1988). How is it enforced? Assume that the left-hand side of every let construct is required to be a non-expansive expression. By assumptions (ii) and (iii), this invariant is preserved by reduction. So,

E_{1} [t]

must be nonexpansive, which, by assumption (i), guarantees that the reduction step does not allocate new memory cells. Then,

μ^{'}

μ

, so

M^{'}

M

1.9.1 Solution: We must first ensure that R-AdD respects

⊑

(Definition 1.7.5). Since the rule is pure, it is sufficient to establish that let

Γ_{0}

[[{\hat{k}}_{1} \hat{+} {\hat{k}}_{2} : T]]

entails let

Γ_{0}

[[\hat{k_{1} + k_{2}} : T]]

. In fact, we have

\begin{aligned} let Γ_{0} in [[{\hat{k}}_{1} \hat{+} {\hat{k}}_{2} : T]] \\ (1) & \equiv & let Γ_{0} in \exists X Y . (\hat{+} ⪯ X \to Y \to T \land {\hat{k}}_{1} ⪯ X \land {\hat{k}}_{2} ⪯ Y) \\ (2) & \equiv & \exists X Y . (int \to int \to int \leq X \to Y \to T \land int \leq X \land int \leq Y) \\ (3) & \equiv & \exists X Y . (X = int \land Y = int \land int \leq T) \\ (4) & \equiv & int \leq T \\ (5) & \equiv & let Γ_{0} in [[\hat{k_{1} + k_{2}} : T]] \end{aligned}

where (1) is by definition of constraint generation; (2) is by definition of

Γ_{0}

, by C-INID and C-IN*; (3) is by C-ARRow and by antisymmetry of subtyping;

(4) is by C-ExAnd and C-NAmE; (5) is again by definition of

Γ_{0}

, by C-InId and

C - {I N}^{*}

, and by definition of constraint generation.

Second, we must check that if the configuration

c v_{1} \dots v_{k} / μ

(where

k \geq 0

) is well-typed, then either it is reducible, or

c v_{1} \dots v_{k}

is a value.

We begin by checking that every value that is well-typed with type int is of the form

\hat{k}

. Indeed, suppose that let

Γ_{0}; ref M

[[v :

int

]]

is satisfiable. Then,

v

cannot be a program variable, for a well-typed value must be closed. v cannot be a memory location

m

, for otherwise ref

M (m) \leq

int would be satisfiable - but the type constructors ref and int are incompatible.

v

cannot be

\hat{+}

\hat{+} v^{'}

, for otherwise int

\to

int

\to

int

\leq

int or int

\to

int

\leq

int would be satisfiable - but the type constructors

\to

and int are incompatible. Similarly,

v

cannot be a

λ

-abstraction. Thus,

v

must be of the form

\hat{k}

, for it is the only case left.

Next, we note that, according to the constraint generation rules, if the configuration

c v_{1} \dots v_{k} / μ

is well-typed, then a constraint of the form let

Γ_{0}

; ref

M

(c ⪯ x_{1} \to \dots \to x_{k} \to T \land [[v_{1} : x_{1}]] \land \dots \land [[v_{k} : x_{k}]])

is satisfiable. We now reason by cases on

c

Case $c$ is $\hat{k}$ . Then, $Γ_{0} (c)$ is int. Because the type constructors int and $\to$ are incompatible with each other, this implies $k = 0$ . Since $\hat{k}$ is a constructor, the expression is a value.
Case $c$ is $\hat{+}$ . We may assume $k \geq 2$ , because otherwise the expression is a value. Then, $Γ_{0} (c)$ is int $\to$ int $\to$ int, so, by C-Arrow, the above constraint entails let $Γ_{0}; ref M$ in $(x_{1} \leq int \land X_{2} \leq int \land [[v_{1} : X_{1}]] \land [[v_{2} : X_{2}]])$ , which, by Lemma 1.6.3, entails let $Γ_{0}; ref M$ in $([[v_{1} : int]] \land [[v_{2}$ : int $]])$ . Thus, $v_{1}$ and $v_{2}$ are well-typed with type int. By the remark above, they must be integer literals ${\hat{k}}_{1}$ and ${\hat{k}}_{2}$ . As a result, the configuration is reducible by R-ADD.

1.9.5 Solution: We must first ensure that R-Ref, R-Deref and R-Assign respect

⊑ (

Definition 1.7.5).

Case R-REF. The reduction is ref v/ $\emptyset ⟶ m / (m \mapsto v)$ , where $m \notin$ fpi(v) (1). Let $T$ be an arbitrary type. According to Definition 1.7.5, the goal is to show that there exist a set of type variables $\bar{Y}$ and a store type $M^{'}$ such that $\bar{Y} # ftv (T)$ and $f t v (M^{'}) \subseteq \bar{Y}$ and $dom (M^{'}) = {m}$ and let $Γ_{0}$ in $[[$ ref $v : T]]$
entails $\exists \bar{Y}$ .let $Γ_{0}$ ; ref $M^{'}$ in $[[m / (m \mapsto v) : T / M^{'}]]$ . Now, we have

\begin{aligned} let Γ_{0} in [[ref v : T]] \\ (2) & \equiv & let Γ_{0} in \exists X Y . (Y \to ref Y \leq X \to T \land [[v : X]]) \\ (3) & \equiv & \exists Y . let Γ_{0} in (ref Y \leq T \land [[v : Y]]) \\ (4) & \equiv & \exists Y . let Γ_{0}; ref M^{'} in (m ⪯ T \land [[v : M^{'} (m)]]) \\ (5) & \equiv & \exists Y . let Γ_{0}; ref M^{'} in [[m / (m \mapsto v) : T / M^{'}]] \end{aligned}

where (2) is by definition of constraint generation and by definition of

Γ_{0} (r e f)

; (3) is by C-Arrow, Lemma 1.6.4, and C-InEx; (4) assumes

M^{'}

is defined as

m \mapsto Y

, and follows from (1), C-INID and C-IN*; and (5) is by definition of constraint generation.

Subcase R-DEREF. The reduction is

! m / (m \mapsto v) ⟶ v / (m \mapsto v)

. Let

T

be an arbitrary type and let

M

be a store type of domain

{m}

. We have

\begin{aligned} let Γ_{0}; ref M in [[! m / (m \mapsto v) : T / M]] \\ (1) & \equiv & let Γ_{0}; ref M in \exists X Y . (ref Y \to Y \leq X \to T \land m ⪯ X \land [[v : M (m)]]) \\ (2) & \equiv & let Γ_{0}; ref M in \exists X Y . (ref M (m) \leq X \leq ref Y \land Y \leq T \land [[v : M (m)]]) \\ (3) & \equiv & let Γ_{0}; ref M in \exists Y . (M (m) = Y \land Y \leq T \land [[v : M (m)]]) \\ (4) & \equiv & let Γ_{0}; ref M in (M (m) \leq T \land [[v : M (m)]]) \\ (5) & ⊩ & let Γ_{0}; ref M in ([[v : T]] \land [[v : M (m)]]) \\ (6) & \equiv & let Γ_{0}; ref M in [[v / (m \mapsto v) : T / M]] \end{aligned}

where (1) is by definition of constraint generation and by definition of

Γ_{0} (!)

; (2) is by C-Arrow and C-InId; (3) follows from C-ExTrans and from the fact that ref is an invariant type constructor; (4) is by C-NAMEEQ; (5) is by Lemma 1.6.3 and C-DuP; and (6) is again by definition of constraint generation.

\circ

Case R-Assign. The reduction is

m := v / (m \mapsto v_{0}) ⟶ v / (m \mapsto v)

. Let

T

be an arbitrary type and let

M

be a store type of domain

{m}

. We have

\begin{aligned} let Γ_{0}; ref M in [[m := v / (m \mapsto v_{0}) : T / M]] \\ (1) & ⊩ & let Γ_{0}; ref M in [[m := v : T]] \\ (2) & \equiv & let Γ_{0}; ref M in \exists X Y Z . (ref Z \to Z \to Z \leq X \to Y \to T \land m ⪯ X \land [[v : Y]]) \\ (3) & \equiv & let Γ_{0}; ref M in \exists X Y Z . (ref M (m) \leq X \leq ref Z \land Z \leq T \land [[v : Y]] \land Y \leq Z) \\ (4) & \equiv & let Γ_{0}; ref M in \exists Z . (M (m) = Z \land Z \leq T \land [[v : Z]]) \\ (5) & \equiv & let Γ_{0}; ref M in (M (m) \leq T \land [[v : M (m)]]) \\ (6) & ⊩ & let Γ_{0}; ref M in [[v / (m \mapsto v) : T / M]] \end{aligned}

where (1) and (2) are by definition of constraint generation; (3) is by CArrow and C-InId; (4) is by C-ExTrans, Lemma 1.6.4, and from the fact that ref is an invariant type constructor; (5) is by C-NAMEEQ; and (6) is obtained as in the previous case.

Second, we must check that if the configuration

c v_{1} \dots v_{k} / μ

(where

k \geq 0

) is well-typed, then either it is reducible, or

c v_{1} \dots v_{k}

is a value. We only give a sketch of this proof; see the solution to Exercise 1.9.1 for details of a similar proof.

We begin by checking that every value that is well-typed with a type of the form ref

T

is a memory location. This assertion relies on the fact that the type constructor ref is isolated.

Next, we note that, according to the constraint generation rules, if the configuration

c_{1} \dots v_{k} / μ

is well-typed, then a constraint of the form let

Γ_{0}

; ref

M

(c ⪯ x_{1} \to \dots \to x_{k} \to T \land [[v_{1} : x_{1}]] \land \dots \land [[v_{k} : x_{k}]])

is satisfiable. We now reason by cases on

c

Case $c$ is ref. If $k = 0$ , then the expression is a value; otherwise, it is reducible by $R$ -REF.
Case c is !. We may assume $k \geq 1$ , because otherwise the expression is a value. Then, by definition of $Γ_{0} (!)$ , the above constraint entails let $Γ_{0}; ref M$ in $\exists Y$ .(ref $Y \to Y \leq X_{1} \to \dots \to X_{k} \to T \land [[v_{1} : X_{1}]])$ , which, by C-Arrow, Lemma 1.6.3, and C-INEx, entails $\exists Y$ .let $Γ_{0}; ref M$ in $[[v_{1} : ref Y]]$ . Thus, $v_{1}$ is well-typed with a type of the form ref $Y$ . By the remark above, $v_{1}$ must be a memory location $m$ . Furthermore, because every well-typed configuration is closed, $m$ must be a member of $dom (μ)$ . As a result, the configuration ref $v_{1} \dots v_{k} / μ$ is reducible by R-DEREF.
Case $c$ is $:=$ . We may assume $k \geq 2$ , because otherwise the expression is a value. As above, we check that $v_{1}$ must be a memory location and a member of $dom (μ)$ . Thus, the configuration is reducible by R-Assign.

1.9.6 Solution: We must first ensure that R-Fix respects

⊑

(Definition 1.7.5). Since the rule is pure, it is sufficient to establish that let

Γ_{0}

[[f i x v_{1} v_{2} : T]]

entails let

Γ_{0}

[[v_{1} (f i x v_{1}) v_{2} : T]]

. Let

C

stand for the constraint fix

⪯

((X \to Y) \to (X \to Y)) \to X \to Y \land Y \leq T \land [[v_{1} : (X \to Y) \to (X \to Y)]] \land [[v_{2} : X]]

. We have

\begin{aligned} let Γ_{0} in [[f i x v_{1} v_{2} : T]] \\ (1) & \equiv & let Γ_{0} in \exists X_{1} X_{2} . (f i x ⪯ X_{1} \to X_{2} \to T \land [[v_{1} : X_{1}]] \land [[v_{2} : X_{2}]]) \\ \equiv & let Γ_{0} in \exists X_{1} X_{2} X Y . (((X \to Y) \to (X \to Y)) \to X \to Y \leq X_{1} \to X_{2} \to T \\ (2) & \land [[v_{1} : X_{1}]] \land [[v_{2} : X_{2}]]) \\ (3) & \equiv & let Γ_{0} in \exists X Y . (Y \leq T \land [[v_{1} : (X \to Y) \to (X \to Y)]] \land [[v_{2} : X]]) \\ (4) & \equiv & let Γ_{0} in \exists X Y . C \end{aligned}

where (1) is by definition of constraint generation; (2) is by definition of

Γ_{0} (f i x); (3)

is by C-ARrow and Lemma 1.6.4;(4) is by definition of

Γ_{0} (f i x)

. By Theorem 1.6.2 and WEAKEn, the judgements

C ⊢ v_{1} : (X \to Y) \to

(X \to Y)

and

C ⊢ v_{2} : X

hold. By Var, Weaken, App, and Sub, it follows that

C ⊢ v_{1} (f i x v_{1}) v_{2} : T

holds. By Theorem 1.6.6, this implies

C ⊩ [[v_{1} (f i x v_{1}) v_{2} : T]]

. By congruence of entailment and by C-Ex*, (4) entails let

Γ_{0}

[[v_{1} (f i x v_{1}) v_{2} : T]]

Second, we must check that if the configuration

f i x v_{1} \dots v_{k} / μ

(where

k \geq 0

) is well-typed, then either it is reducible, or

f i x v_{1} \dots v_{k}

is a value. This is immediate, for it is a value when

k < 2

, and it is reducible by R-FIX when

k \geq 2

We now recall that the construct letrec

f = λ

z.t

_{1}

t_{2}

provided by ML-the-programming-language may be viewed as syntactic sugar for let

f =

fix

(λ f . λ z . t_{1})

t_{2}

, and set forth to discover the constraint generation rule that arises out of such a definition. We have

\begin{aligned} let Γ_{0} in [[f i x (λ f . λ z . t_{1}) : T]] \\ (1) & \equiv & let Γ_{0} in \exists Z . (f i x ⪯ Z \to T \land [[λ f . λ z \cdot t_{1} : Z]]) \\ (2) & \equiv & let Γ_{0} in \exists X Y . (X \to Y \leq T \land [[λ f f . λ z . t_{1} : (X \to Y) \to (X \to Y)]]) \\ (3) & \equiv & let Γ_{0} in \exists X Y . (X \to Y \leq T \land let f : X \to Y; z : X in [[t_{1} : Y]]) \end{aligned}

where (1) is by definition of constraint generation; (2) is by definition of

Γ_{0}

(fix), by C-ARrow, and by Lemma 1.6.4; and (3) follows from Lemma 1.6.5. This allows us to write

\begin{aligned} let Γ_{0} in [[let f = f i x (λ f . λ z . t_{1}) in t_{2} : T]] \\ \equiv let Γ_{0}; f : \forall z [[[f i x (λ f \cdot λ z \cdot t_{1}) : z]]] . z in [[t_{2} : T]] \\ \equiv let Γ_{0}; f : \forall Z [\exists X Y . (X \to Y \leq Z \land let f : X \to Y; z : X in [[t_{1} : Y]])] . Z in [[t_{2} : T]] \\ \equiv let Γ_{0}; f : \forall X Y [let f : X \to Y; z : X in [[t_{1} : Y]]] . X \to Y in [[t_{2} : T]] \end{aligned}

where (4) is by definition of constraint generation; (5) follows from C-LETDuP and from the previous series of equivalences; (6) is by C-LETEx, C-ExTrans and Lemma 1.3.22.

1.9.21 Solution: We have

\begin{aligned} {match}_{1} with z \cdot t_{2} : T]] \\ (1) & \equiv & let \forall x X^{'} [[[t_{1} : x]] \land let z : X^{'} in [[X : z]]] \cdot (z : X^{'}) in [[t_{2} : T]] \\ (2) & \equiv & let z : \forall X^{'} [\exists X \cdot ([[t_{1} : x]] \land X \leq X^{'})] \cdot X^{'} in [[t_{2} : T]] \\ (3) & \equiv & let z : \forall X^{'} [[[t_{1} : X^{'}]]] \cdot X^{'} in [[t_{2} : T]] \\ (4) & \equiv & [[let z = t_{1} in t_{2} : T]] \end{aligned}

where (1) is by definition of constraint generation for match; (2) is by definition of constraint generation for patterns, by C-InID, C-IN*, and C-LETEx; (3) is by Lemma

1.6 .4; (4)

is by definition of constraint generation for let.

1.9.26 Solution: The type scheme

\forall \bar{X} . T \to T

may be written

\forall \bar{X}

[X \mapsto T] (X \to X)

. Furthermore,

\bar{X} # \forall X . X \to X

holds. Thus,

\forall \bar{X} . T \to T

is an instance of

\forall X . X \to X

in the sense of DM-INST'. Since DM-InsT' is an admissible rule for the type system DM, and since it is clear that the identity function

λ z . z

has type

\forall X . X \to X

, it must also have type

\forall \bar{X} . T \to T

. (A more direct proof of this fact would not be difficult.) So, the destructor

(\cdot : \exists \bar{X} . T)

has not only identity semantics, but also an identity type. This shows that our definitions are sound.

Let us now check requirement (i) of Definition 1.7.6. Since R-Annotation is pure, it suffices to show that let

Γ_{0}

[[(v : \exists \bar{X} . T) : T^{'}]]

entails let

Γ_{0}

[[v : T^{'}]]

Now, we have

\begin{matrix} (3) & \begin{array}{ll} let Γ_{0} in [[(v : \exists \bar{X} . T) : T^{'}]] \\ \equiv & let Γ_{0} in \exists X \bar{X} \cdot (T \to T \leq X \to T^{'} \land [[v : X]]) \\ \equiv & let Γ_{0} in \exists X \bar{X} \cdot (X \leq T \leq T^{'} \land [[v : X]]) \\ ⊩ & let Γ_{0} in [[v : T^{'}]] \end{array} \end{matrix}

where (1) is by definition of constraint generation and by definition of

Γ_{0} ((\cdot

\exists \bar{X} . T)

); (2) is by C-ArRow; and (3) follows from Lemma 1.6.3 and C-EX*.

1.10.5 Solution: We have

\begin{aligned} let Γ_{0} in \exists z \cdot [[(λ z \cdot z \hat{+} \hat{1} : \forall X . X \to X) : Z]] \\ (1) & \equiv & let Γ_{0} in \exists z \cdot (\forall x \cdot [[λ z \cdot z \hat{+} : X \to X]] \land \exists X . (X \to X \leq z)) \\ (2) & \equiv & let Γ_{0} in \forall x . let z : x in [[z \hat{+} \hat{1} : x]] \\ (3) & \equiv & \forall x . (int \to int \to int \leq X \to int \to X) \\ (4) & \equiv & \forall x . (X = int) \\ (5) & \equiv & false \end{aligned}

where (1) is by definition of constraint generation for universal type annotations; (2) is obtained by restricting the scope of

\exists Z

to the second conjunct, then dropping the latter altogether, since it is equivalent to true, and by Lemma 1.6.5; (3) is obtained by definition of constraint generation, by definition of

Γ_{0} (\hat{+})

and of

Γ_{0} (\hat{1})

, and by a few simple equivalence laws; (4) follows from C-ARrow and antisymmetry of subtyping; (5) follows from the fact that int and (say) int

\to

int have distinct interpretations, since the type constructors int and

\to

are incompatible. On the other hand, we have

\begin{aligned} let Γ_{0} in \exists Z \cdot [[(λ z \cdot z : \forall X . X \to X) : Z]] \\ (1) & \equiv & let Γ_{0} in \forall X . let z : X in [[z : X]] \\ (2) & \equiv & \forall X . (X \leq X) \\ (3) & \equiv & true \end{aligned}

where (1) is obtained as above; (2) by definition of constraint generation, C-InID and C-IN*; (3) is by reflexivity of subtyping.

1.10.6 Solution: Under the naïve constraint generation rule for universal type variable introduction, the constraint

[[\forall X . (λ z \cdot z : X \to X) : Z]]

is equivalent to

\forall X . ([[λ z . z : X \to X]] \land X \to X \leq Z)

. Since the first conjunct is a tautology, this is in turn equivalent to

\forall X

(X \to X \leq Z

). In a nondegenerate free term model where subtyping is interpreted as equality, this constraint is unsatisfiable. In a non-structural subtyping model equipped with a least type

⊥

and a greatest type

⊤

, it is equivalent to

⊥\to ⊤ \leq Z

. This is a pretty restrictive constraint: since no value has type

⊥

, a function whose type is (a supertype of)

⊥\to T

cannot ever be invoked at runtime. This situation is clearly unsatisfactory. Checking that

\forall X . [[λ z . z : X \to X]]

holds was indeed part of our intent, but constraining

Z

to be a supertype of

X \to X

for every

X

was not.

\bar{X} # f t v (T^{'})

(3). By (1), (2), (3), and by definition of constraint generation for local universal type annotations,

[[(t : \forall \bar{X} . T) : T^{'}]]

is well-defined and is

\forall \bar{X} . [[t : T]] \land \exists \bar{X} . (T \leq T^{'})

(4). By (3) and by definition of constraint generation for introduction of universal type variables and for general type annotations,

[[\forall \bar{X} . (t : T) : T^{'}]]

\forall \bar{X} \cdot \exists Z . ([[t : T]] \land T \leq Z) \land \exists \bar{X} . ([[t : T]] \land T \leq T^{'})

, where

Z

is fresh, which we may immediately simplify to

\forall \bar{X}

[[t : T]] \land \exists \bar{X}

([[t : T]] \land T \leq T^{'})

(5). Using C-ExAnd and Lemma 1.10.1, it is straightforward to check that (4) and (5) are equivalent.

1.10.9 Solution: We have

\begin{matrix} (2) & \begin{array}{ll} \exists Z \cdot [[λ z \cdot \forall X \cdot (z : x) : z]] \\ ⊩ & \exists Z_{1} Z_{2} \cdot let z : Z_{1} in [[\forall X . (z : x) : Z_{2}]] \\ IF & \exists Z_{1} \cdot \forall X \cdot (Z_{1} \leq X) \end{array} \end{matrix}

where (1) is by definition of constraint generation for

λ

-abstractions, dropping the constraint that relates

Z, Z_{1}

, and

Z_{2}; (2)

is by definition of constraint generation for universal type variable introduction, this time dropping information about

Z_{2}

. Now, in a nondegenerate equality model, the constraint (2) is equivalent to false. In fact, for (2) to be satisfiable, the interpretation of subtyping must admit a least element

⊥

. We now see that

[[λ z . \forall X . (z : X) : Z]]

is a very restrictive constraint. Indeed, it requires

z

to have every type at once. Because

z

λ

-bound-hence monomorphic-it must in fact have type

⊥

. On the other hand, we have

\begin{aligned} \exists Z \cdot [[\forall X \cdot λ z \cdot (z : X) : Z]] \\ (1) & \equiv & \forall x \cdot \exists Z \cdot [[λ z \cdot (z : x) : Z]] \\ (2) & \equiv & \forall X \cdot \exists Z Z Z_{1} \cdot (Z_{2} \leq X \land X \leq Z_{2} \land Z_{1} \to Z_{2} \leq Z) \\ (3) & \equiv & true \end{aligned}

where (1) is by definition of constraint generation for universal type variable introduction, dropping the second conjunct, which is entailed by the first; (2) is by Lemma 1.6.5, by definition of constraint generation for general type annotations, and by a few simple equivalence laws; (3) follows from C-NAMEEQ and the witness substitution

[Z_{1} \mapsto X, Z_{2} \mapsto X, Z \mapsto (X \to X)]

\begin{aligned} \equiv let f : \forall x [[[f i x f : S . λ z . t_{1} : x]]] . x in [[t_{2} : T]] \\ \equiv let f : \forall X [let f : S in [[λ z . t_{1} : S]] \land S ⪯ X] . X in [[t_{2} : T]] \\ \equiv let f : S in [[λ z . t_{1} : S]] \land let f : \forall x [S ⪯ x] . x in [[t_{2} : T]] \\ \equiv let f : S in ([[λ z \cdot t_{1} : S]] \land [[t_{2} : T]]) \end{aligned}

where (1) is by definition of the letrec syntactic sugar and by the definition of constraint generation for let constructs; we have

X \notin f t v (S, t_{1})

; (2) is by definition of constraint generation for fix; (3) is by C-LETAND; (4) follows from the equivalence between the type schemes

\forall X [S ⪯ X] . X

and

S

- which itself is a direct consequence of C-ExTRAns-and from C-InAnd.

1.11.16 Solution: We reason simultaneously in both the subtyping model or the equal-only model, that is, we only rely on properties that are valid in both models.

We must first ensure that rules RD-DEFAULT, RD-Found, and RD-FolLow respect (Definition 1.7.5).

Case RD-DEfault. The reduction is ${v} . {ℓ} \overset{δ}{\to} v$ , which is pure. Therefore, it is sufficient to establish that let $Γ_{0}$ in $[[{v} \cdot {ℓ} : T]]$ entails let $Γ_{0}$ in $[[v : T]]$ . In fact, we have:

\begin{matrix} (5) & \begin{array}{cc} let Γ_{0} in [[{v} \cdot {ℓ} : T]] \\ \equiv & let Γ_{0} in \exists X Y . (\cdot . {ℓ} ⪯ X \to T \land {\cdot} ⪯ Y \to X \land [[v : Y]]) \\ \equiv & let Γ_{0} in \exists X Y . (\exists X_{1} X_{2} \cdot (Π (ℓ : X_{1}; X_{2}) \to X_{1} \leq X \to T) \\ \land \exists Y_{1} \cdot (Y_{1} \to Π (\partial Y_{1}) \leq Y \to X) \land [[v : Y]]) \\ ⊩ & let Γ_{0} in \exists X_{2} Y . (\partial Y \leq (ℓ : X_{1}; X_{2}) \land X_{1} \leq T \land [[v : Y]]) \\ ⊩ & let Γ_{0} in \exists Y . (Y \leq X_{1} \land X_{1} \leq T \land [[v : Y]]) \\ ⊩ & let Γ_{0} in [[v : T]] \end{array} \end{matrix}

where (1) is by definition of constraint generation; (2) is by definition of

Γ_{0}

, C-InId; (3) by variances of

Π, ℓ

, and

\to

, C-And, C-Ex*, C-ExAnd; (4) by C-Row-DL and covariance of

ℓ

; (5) by Lemma 1.6.3.

○ Case RD-Found: The reduction is

{w

with

ℓ = v} . {ℓ} \overset{δ}{\to} v

. It suffices to establish let

Γ_{0}

[[{w

with

ℓ = v} \cdot {ℓ} : T]]

entails let

Γ_{0}

[[v : T]]

. In fact, we
have:

\begin{aligned} let Γ_{0} in [[{w with ℓ = v} \cdot {ℓ} : T]] \\ \equiv & let Γ_{0} in \exists {X Y Y}^{'} \cdot (\cdot : {ℓ} ⪯ X \to T \land {\cdot with ℓ = \cdot} ⪯ Y \to Y^{'} \to X \land \\ (1) & \land & \land [[w : Y]] \land [[v : Y^{'}]]) \\ \equiv & let Γ_{0} in \exists {X Y Y}^{'} \cdot (\exists X_{1} X_{2} \cdot (Π (ℓ : X_{1}; X_{2}) \to X_{1} \leq X \to T) \\ \land \exists Y_{1} Y_{2} Y_{3} \cdot (Π (ℓ : Y_{1}; Y_{3}) \to Y_{2} \to Π (ℓ : Y_{2}; Y_{3}) \leq Y \to Y^{'} \to X) \\ (2) & \land [[w : Y]] \land [[v : Y^{'}]]) \\ (3) & I & let Γ_{0} in \exists Y^{'} X_{1} Y_{2} \cdot (Y^{'} \leq Y_{2} \land Y_{2} \leq X_{1} \land X_{1} \leq T \land [[v : Y^{'}]]) \\ (4) & I & let Γ_{0} in [[v : T]] \end{aligned}

where (1) is by definition of constraint generation; (2) is by definition of

Γ_{0}

, C-InID; (3) by variances of

Π, ℓ

, and

\to

, C-And, C-Ex*, C-ExAnd; (4) by Lemma 1.6.3.

Case RD-Follow The proof is similar to the previous case.

We must now check that if the configuration

F v_{1} \dots v_{k} / μ

is is well-typed, then either it is reducible, or it is a value.

We begin by checking that every value that is well-typed with type

Π T

is a record value, that is, either of the form

{v^{'}}

{v^{''}

with

ℓ^{'} = v^{'}}

. Indeed, suppose that let

Γ_{0}

[[v : Π T]]

is satisfiable. Then,

v

cannot be a program variable, for a well-typed value must be closed;

v

cannot be a memory location

m

, for otherwise ref

M (m) \leq Π T

would be satisfiable - but the top type constructors ref and

Π

are incompatible (since

Π

is isolated); v cannot be a partial application of a constructor or a primitive, nor a

λ

-abstraction, since otherwise

T^{'} \to T^{''} \leq Π T

would be satisfiable but the top type constructors

\to

and

Π

are incompatible (since they are both isolated); thus v must either be of the form

{v}

{w

with

ℓ = v}

, for these are the only left cases.

Next, we note that, according to the constraint generation rules, if the configuration

c_{1} \dots v_{k} / μ

is well-typed, then a constraint of the form let

Γ_{0}; ref M

(c ⪯ x_{1} \to \dots \to x_{k} \to T \land [[v_{1} : x_{1}]] \land \dots \land [[v_{k} : x_{k}]])

is satisfiable. We now reason by cases on

c

\circ

Case

c

{\cdot}

. We may asume

k \geq 2

, since otherwise, the expression is a value. Then

Γ_{0} (c)

\forall X Y . X \to Π (\partial X)

, so by C-INID and C-ARROw the above constraint entails

\exists X . (Π (\partial X) \leq X_{2} \to \dots \to T)

, which by C-Class-I entails false since

\to

and

Π

are imcompatible. Thus, this case cannot occur.

\circ

Case

c

{\cdot

with

ℓ = \cdot}

. Similar to the previous case.

\circ

Case

c

\cdot {ℓ}

. We may asume

k \geq 1

, since otherwise, the expression is a value. Then

Γ_{0} (c)

\forall X Y . Π (ℓ : X; Y) \to X

, so by C-INID and C-ARRow the above constraint entails let

Γ_{0}; ref M

(\exists X Y . (X_{1} \leq Π (ℓ : X; Y)) \land [[v_{1} : X_{1}]])

, which by lemma 1.6.3 entails let

Γ_{0}; ref M

\exists X Y . [[v_{1} : Π (ℓ : X; Y)]]

. Thus

v_{1}

is a record value, that is, either of the form

{v^{'}}

and the configuration is reducible
to

v^{'}

or of the form

{v^{''}

with

ℓ^{'} = v^{'}}

and the configuration is reducible to either

v^{'}

v^{''} . {ℓ}

1.11.17 Solution: We add a collection of destructors

\cdot [ℓ_{1} \leftrightarrow ℓ_{2}]

of arity 1 for all pairs of distinct labels, with the following semantics:

\begin{array}{rr} {v} [ℓ_{1} \leftrightarrow ℓ_{2}] \overset{δ}{\to} v \\ {w with ℓ = v} [ℓ_{1} \leftrightarrow ℓ_{2}] \overset{δ}{\to} {w [ℓ_{1} \leftrightarrow ℓ_{2}] with ℓ = v} & if ℓ \notin {ℓ_{1}, ℓ_{2}} \\ {w with ℓ = v} [ℓ_{1} \leftrightarrow ℓ_{2}] \overset{δ}{\to} {w [ℓ_{1} \leftrightarrow ℓ_{2}] with \bar{ℓ} = v} & if {ℓ, \bar{ℓ}} = {ℓ_{1}, ℓ_{2}} \end{array}

The initial environment

Γ_{0}

must be extended with the following typing asumption:

\cdot [ℓ_{1} \leftrightarrow ℓ_{2}] : \forall X_{1} X_{2} Y \cdot Π (ℓ_{1} : X_{1}; ℓ_{2} : X_{2}; Y) \to Π (ℓ_{1} : X_{2}; ℓ_{2} : X_{1}; Y)

We must then check subjection reduction for the new primitive. Since we only added a constructor, it sufficies to check progress for the new primitive, that is, that well-typed expressions of the form

[ℓ_{1} \leftrightarrow ℓ_{2}] v_{1} \dots v_{n}

are either value or can be further reduced. Both parts are easy and similar to the corresponding parts in Exercice 1.11.16.

1.11.18 Solution: There are several solutions. One of them is to asume a fixed total ordering on row-labels, and to retain as constructors only

ℓ^{κ, L}

such that

ℓ < L

, that is

ℓ < ℓ^{'}

for all

ℓ^{'} \in L

; other constants

ℓ^{κ, L}

such that

ℓ ≮ L

are moved from constructors to the status of destructors with the following collection of reduction rules:

{{w with ℓ^{'} = v^{'}} with ℓ = v} \overset{δ}{\to} {{w with ℓ = v} with ℓ^{'} = v^{'}}

(RD-TRANSPOSE)

for all labels

ℓ

and

ℓ^{'}

such that

ℓ^{'} < ℓ

and

{{w with ℓ = v^{'}} with ℓ = v} \overset{δ}{\to} {w with ℓ = v}

(RD-DISCARD)

for all labels

ℓ

. It is now obvious that values are in normal forms, in the sense that explicit fields are never repeated and are always listed in order. Typing rules need not be changed, so requirement (i) of Definition 1.7.6 still holds. Requirement (ii) need to be check, in particular, for the new primitives

ℓ^{L}

, which we leave to the reader (the proof for

\cdot . {ℓ}

should hold unchanged).

1.11.19 Solution: Let map have type

Π (X \to Y) \to Π (X) \to Π (Y)

, and the following reduction rules in the semantics with normal forms:

\begin{matrix} map {v^{'} with ℓ = v} w \overset{δ}{\to} {map v^{'} w with ℓ = v (w \cdot {ℓ})} \\ map v {w^{'} with ℓ = w} \overset{δ}{\to} {map v w^{'} with ℓ = (v \cdot {ℓ}) w} \\ map {v} {w} \overset{δ}{\to} {v w} \end{matrix}

1.11.22 Solution: To ensure that the field is not present in the argument of extension, it sufficies to restrict its the typing asumptions as follows:

⟨ \cdot with ℓ = \cdot ⟩ : \forall {X x}^{'} Y . Π (ℓ : abs; Y) \to X^{'} \to Π (ℓ : pre X^{'}; Y)

To remove an existing field, we can use the following syntactic sugar:

\begin{aligned} \cdot ∖ ℓ \overset{def}{=} & λ v \cdot {v with ℓ = a b s} \\ : \forall X Y . Π (ℓ : X; Y) \to Π (ℓ : abs; Y) \end{aligned}

The following weaker typing asumption could also be used to ensure that the field is always present before removal:

\forall X Y . Π (ℓ : pre X; Y) \to Π (ℓ : abs; Y)

1.11.25 Solution: The proof is similar to 1.11 .16 but slightly more complex because we must also check that labels are defined when accessed, and with subtyping.

We reason simultaneously in both the subtyping model or the equal-only model, that is, we only rely on properties that are valid in both models.

We must first ensure that rules RE-FOUND and RE-FOLLOW respect (Definition 1.7.5).

Case RE-Found: See Exercice ??. In line ??, field $ℓ$ is pre $X_{1}$ instead of $X_{1}$ and pre $Y_{2}$ instead of $Y_{2}$ and step ?? also uses covariance of pre.
Case RE-Follow The proof is similar.

We must then check that if the configuration

F v_{1} \dots v_{k} / μ

is is well-typed, then either it is reducible, or it is a value.

We begin by checking that every value that is well-typed with type

Π T

is a record value, that is, either of the form \langle\rangle or

⟨ v^{''}

with

ℓ^{'} = v^{'} ⟩

. See Exercice 1.11.16.

Next, we note that, according to the constraint generation rules, if the configuration

c v_{1} \dots v_{k} / μ

is well-typed, then a constraint of the form let

Γ_{0}; ref M

(c ⪯ x_{1} \to \dots \to x_{k} \to T \land [[v_{1} : x_{1}]] \land \dots \land [[v_{k} : x_{k}]])

is satisfiable. We now reason by cases on

c

\circ

Case

c

is \langle\rangle or

⟨ \cdot

with

ℓ = \cdot ⟩

. See Exercice 1.11.16.

\circ

Case

c

\cdot ⟨ ℓ ⟩

. We may asume

k \geq 1

, since otherwise, the expression is a value. Then

Γ_{0} (c)

\forall X Y . Π (ℓ

: pre

X; Y) \to X

, so by C-INID and C-ARRow the above constraint entails let

Γ_{0}; ref M

(\exists X Y . (X_{1} \leq Π (ℓ :

pre

X; Y)) \land [[v_{1} : X_{1}]])

, which by lemma 1.6.3 entails let

Γ_{0}; ref M

\exists X Y . [[v_{1} : Π (ℓ :

pre

X; Y)]]

. Thus

v_{1}

is a record value, that is, either of the form \langle\rangle or

⟨ v^{''}

with

ℓ = v^{'} ⟩

. In fact, the former case cannot occur, since let

Γ_{0}; ref M

\exists X Y . [[⟨ ⟩ : Π (ℓ :

pre X ; Y)】 entails

\exists X Y Π (\partial a b s) \leq Π (ℓ

: pre X;

)

by C-INID and C-IN*, which in turns
entails

\exists

X.abs

\leq

pre

X

by C-Row-DL and covariance of

Π

and

ℓ

. However, this constraint is equivalent to false, because

ϕ (a b s) \leq ϕ

(pre

X

) does not hold in any ground assignment

ϕ

. Thus

v_{1}

⟨ v^{''}

with

ℓ^{'} = v^{'} ⟩

and the configuration is reducible to

v^{'}

ℓ^{'}

ℓ

v^{''}

otherwise.

The (currently unfinished) code that accompanies this chapter may be found at http: //pauillac.inria.fr/ remy/mlrow/. For space reasons, some material, including proofs, exercises, and more, has been left out of this version. In the future, a full version of this chapter that includes the missing material will be made available at the same address. In spite of these omissions, this chapter is still oversize with respect to Benjamin's 100 page barrier: we currently have roughly 135 pages of text and 15 pages of solutions to exercises. We would appreciate comments and suggestions from the proofreaders as to how this chapter could be made shorter, without severely compromising its interest or readability.

1 M L 1 M L 1ML1 M L1ML

By François Pottier and Didier Rémy

1.1 Preliminaries

Names and renaming

1.2 What is ML?

ML-the-calculus

Damas and Milner's type system

Road map

1.3 Constraints

Syntax

Meaning

Reasoning with constraints

Reasoning with constraints in an equality-only syntactic model

1.4 HM ⁡ ( X ) 1.4 HM ⁡ ( X ) 1.4 HM(X)1.4 \operatorname{HM}(X)1.4HM⁡(X)

Definition

An alternate presentation of H M ( X ) H M ( X ) HM(X)\mathrm{HM}(\boldsymbol{X})HM(X)

Relating H M ( X ) H M ( X ) HM(X)\mathrm{HM}(X)HM(X) with Damas and Milner's type system

1.5 A purely constraint-based type system: PCB ⁡ ( X ) PCB ⁡ ( X ) PCB(X)\operatorname{PCB}(X)PCB⁡(X)

Presentation

Relating PCB ⁡ ( X ) PCB ⁡ ( X ) PCB(X)\operatorname{PCB}(X)PCB⁡(X) with HM ⁡ ( X ) HM ⁡ ( X ) HM(X)\operatorname{HM}(X)HM⁡(X)

1.6 Constraint generation

1.7 Type soundness

1.8 Constraint solving

Unification

Figure 1-11: Unification

A constraint solver

1.9 From ML-the-calculus to ML-the-programming-language

Simple extensions

Algebraic data types

Pattern matching

1.9.23 ThEOREM [SUBJECT REDUCTION]: (R-MATCH) ⊆ ( ⊑ ) ⊆ ( ⊑ ) sube(⊑)\subseteq(\sqsubseteq)⊆(⊑)

Type annotations

Recursive types

1.10 Universal quantification in constraints

Constraints

Constraint solving

Figure 1-16: Solving universal constraints

Type annotations, continued

Polymorphic recursion

Universal types

Existential types

1.11 Rows

Records with finite carrier

Records with infinite carrier

Syntax of row types

Meaning of rows

Reasoning with row types

Figure 1-17: Equational reasoning for row types.

Figure 1-18: Constraint equivalence laws for rows.

Solving row constraints in an equality model

Figure 1-19: Unification addendum for row types

Operations on records

Record concatenation

Polymorphic variants

Other applications of rows

Alternatives to rows

1.10.5 Solution: We have

$1 M L$

$1.4 HM (X)$

An alternate presentation of $H M (X)$

Relating $H M (X)$ with Damas and Milner's type system

1.5 A purely constraint-based type system: $PCB (X)$

Relating $PCB (X)$ with $HM (X)$

1.9.23 ThEOREM [SUBJECT REDUCTION]: (R-MATCH) $\subseteq (⊑)$